[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <C3BAD228-118B-4810-9FA0-6007EEE62368@me.com>
Date: Thu, 09 Feb 2017 12:25:43 -0800
From: Denny Page <dennypage@...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>,
Willem de Bruijn <willemb@...gle.com>
Subject: Re: Extending socket timestamping API for NTP
> On Feb 08, 2017, at 16:45, Denny Page <dennypage@...com> wrote:
>
> [Resend as plain text]
>
>
>> On Feb 07, 2017, at 06:01, 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.
>>
>> 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
Powered by blists - more mailing lists