> On Feb 08, 2017, at 16:45, Denny Page <dennyp...@me.com> wrote: > > [Resend as plain text] > > >> On Feb 07, 2017, at 06:01, Miroslav Lichvar <mlich...@redhat.com> wrote: >> >> 5) new SO_TIMESTAMPING options to get transposed RX timestamps >> >> PTP uses preamble RX timestamps, but NTP works with trailer RX >> timestamps. This means NTP implementations currently need to >> transpose HW RX timestamps. The calculation requires the link speed >> and the length of the packet at layer 2. It seems this can be >> reliably done only using raw sockets. It would be very nice if the >> kernel could tranpose the timestamps automatically. >> >> The existing SOF_TIMESTAMPING_RX_HARDWARE flag could be aliased to >> SOF_TIMESTAMPING_RX_HARDWARE_PREAMBLE and the new flag could be >> SOF_TIMESTAMPING_RX_HARDWARE_TRAILER. >> >> PTP has a similar problem with SW RX timestamps, which are closer >> to the trailer timestamps rather than preamble timestamps. A new >> SOF_TIMESTAMPING_RX_SOFTWARE_PREAMBLE flag could be added for PTP >> implementations to get transposed timestamps in order to improve >> accuracy. >> >> 6) new SO_TIMESTAMPING option to get PHC index with HW timestamps >> >> With bridges, bonding and other things it's difficult to determine >> which PHC timestamped the packet. It would be very useful if the >> PHC index was provided with each HW timestamp. >> >> I'm not sure what would be the best place to put it. I guess the >> second timespec in scm_timestamping could be reused for this, but >> that sounds like a gross hack. Do we need to define a new struct? > > > Miroslav, if #5 were implemented, would #6 still needed? > > Denny
Miroslav, please ignore this. Of course you still need the index in order to get the PHC offset. My bad. Denny
