netdev - Re: Extending socket timestamping API for NTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Feb 2017 11:42:45 -0800
From:   sdncurious <sdncurious@...il.com>
To:     Miroslav Lichvar <mlichvar@...hat.com>
Cc:     Richard Cochran <richardcochran@...il.com>,
        netdev <netdev@...r.kernel.org>, Jiri Benc <jbenc@...hat.com>,
        "Keller, Jacob E" <jacob.e.keller@...el.com>,
        Denny Page <dennypage@...com>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: Extending socket timestamping API for NTP

>
>> > 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.