Thread (32 messages) 32 messages, 7 authors, 2017-03-24

Re: Extending socket timestamping API for NTP

From: Miroslav Lichvar <hidden>
Date: 2017-03-23 16:21:48

On Thu, Feb 09, 2017 at 12:09:41PM +0100, Miroslav Lichvar wrote:
On Thu, Feb 09, 2017 at 09:02:42AM +0100, Richard Cochran wrote:
quoted
On Tue, Feb 07, 2017 at 03:01:44PM +0100, Miroslav Lichvar wrote:
quoted
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.
After becoming a bit more familiar with the code I don't think this is
a good idea anymore :). I suspect there would be a noticeable
performance impact if each timestamped packet could trigger reading of
the current link speed. If the value had to be cached it would make
more sense to do it in the application.

With no option to get transposed timestamps the point 6 can be
scratched too.

A better approach might be a control message that would provide the
original interface index together with the length of the packet, so
the application could transpose the HW timestamp and map the HW
interface to the PHC.

The two values could be saved in the skb_shared_info structure. Now
my question is if they could be useful also for other things than
timestamping and if it should be a new socket option which would work
on any socket independently from timestamping, or if it should rather
be a new flag for the SO_TIMESTAMPING option. If the latter, would it
make sense to put them in the skb_shared_hwtstamps structure and
modify all drivers to set the values when a HW timestamp is captured
instead of adding more code to __netif_receive_skb_core() or similar?

What do you think?
quoted
quoted
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.
-- 
Miroslav Lichvar
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help