> >> > 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. >> >> Impossible, because the link speed may change between the time when >> the MAC receives the data the kernel gets around to calculating the >> time stamp. > > I think that would be an acceptable limitation. The application > certainly couldn't do a better job than the kernel and it won't have > to use raw sockets. >
As you are using HW that supports NTP time stamping won't it by default time stamp the receiving packet correctly at the CRC ? Or if someone came out with such a HW than what ? I am still at a loss as to why transpose is required in case of HW time stamping. If STF is used for both Tx and Rx time stamping the timing is absolutely correct. Any delay in the PHY is nothing more than usual kernel processing delay, which NTP should be able to deal with when trying to calculate the round trip time, unless there is an issue with the algorithm. The application can even calculate the complete delay in kernel processing if we provide another time stamp when the packet is read by the application. That seems to provide more accuracy and seems like a better idea. RMS.
