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]

Message-ID: <CAHoNx59VwLbACPp_3a5doyi=Y1hUqU5oVvJqxpsv777W2g+Z8w@mail.gmail.com>
Date:   Tue, 7 Feb 2017 12:37:15 -0800
From:   sdncurious <sdncurious@...il.com>
To:     Miroslav Lichvar <mlichvar@...hat.com>
Cc:     netdev@...r.kernel.org, Richard Cochran <richardcochran@...il.com>,
        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

On Tue, Feb 7, 2017 at 6:01 AM, Miroslav Lichvar <mlichvar@...hat.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.

Is this a requirement ? RFC 5905 does not seem to imply this and a
search  does not show any issues being reported.
>From RFC 5905

   Reference Timestamp: Time when the system clock was last set or
   corrected, in NTP timestamp format.

   Origin Timestamp (org): Time at the client when the request departed
   for the server, in NTP timestamp format.

   Receive Timestamp (rec): Time at the server when the request arrived
   from the client, in NTP timestamp format.

   Transmit Timestamp (xmt): Time at the server when the response left
   for the client, in NTP timestamp format.

   Destination Timestamp (dst): Time at the client when the reply
   arrived from the server, in NTP timestamp format.

   Note: The Destination Timestamp field is not included as a header
   field; it is determined upon arrival of the packet and made available
   in the packet buffer data structure.

   If the NTP has access to the physical layer, then the timestamps are
   associated with the beginning of the symbol after the start of frame.
   Otherwise, implementations should attempt to associate the timestamp
   to the earliest accessible point in the frame.

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

What is the use case for this. even if the delay though the PHY's how
would that be compensated ?

RMS
>
> Thoughts?
>
> --
> Miroslav Lichvar