Re: Extending socket timestamping API for NTP

> On Mar 27, 2017, at 13:58, Richard Cochran wrote: > > On Mon, Mar 27, 2017 at 12:18:47PM -0700, Denny Page wrote: >> I think that on average, the Vendor’s numbers are likely to be more >> accurate than anyone else’s. The concept that independent software >>

Re: Extending socket timestamping API for NTP

On Mon, Mar 27, 2017 at 12:19:57PM -0700, Denny Page wrote: > Do you still have the resulting correction values from this? No, I don't, but next time I drag out the phyter I will take another look and let you know. Thanks, Richard

Re: Extending socket timestamping API for NTP

On Mon, Mar 27, 2017 at 12:18:47PM -0700, Denny Page wrote: > I think that on average, the Vendor’s numbers are likely to be more > accurate than anyone else’s. The concept that independent software > implementations are going to somehow obtain and maintain better > numbers is too much of a

Re: Extending socket timestamping API for NTP

[Resend in plain text for vger] > On Mar 27, 2017, at 11:28, Richard Cochran wrote: > > I didn't do anything super methodical, and I didn't keep notes, but I > had a phyter (whose delays were published by TI and independently > confirmed in a ISPCS paper by Christian

Re: Extending socket timestamping API for NTP

[Resend in plain text for vger] > On Mar 27, 2017, at 11:28, Richard Cochran wrote: > > On Mon, Mar 27, 2017 at 09:25:03AM -0700, Denny Page wrote: > >> I agree that the values in the igb driver are incorrect. They were >> middle of the range values from the old

Re: Extending socket timestamping API for NTP

> On Mar 27, 2017, at 11:28, Richard Cochran wrote: > > On Mon, Mar 27, 2017 at 09:25:03AM -0700, Denny Page wrote: > >> I agree that the values in the igb driver are incorrect. They were >> middle of the range values from the old tables. At least for 100Mb, >> Intel

Re: Extending socket timestamping API for NTP

On Mon, Mar 27, 2017 at 09:25:03AM -0700, Denny Page wrote: > I agree that the values in the igb driver are incorrect. They were > middle of the range values from the old tables. At least for 100Mb, > Intel seems to know that the original table was incorrect. I’ve done > extensive measurements of

Re: Extending socket timestamping API for NTP

> On Mar 27, 2017, at 07:29, Richard Cochran wrote: > > At the end of the day, the correction in the igb driver is useless and > even harmful. Why? Because if the app cares about this level of > accuracy, it is going to have to implement special logic anyhow, and >

Re: Extending socket timestamping API for NTP

On Mon, Mar 27, 2017 at 12:13:24PM +0200, Miroslav Lichvar wrote: > On Fri, Mar 24, 2017 at 10:17:51AM -0700, Denny Page wrote: > > I should have remembered this yesterday... I went and looked at my favorite > > driver, Intel's igb. Not only is the igb driver already caching link speed, > > it

Re: Extending socket timestamping API for NTP

On Fri, Mar 24, 2017 at 10:17:51AM -0700, Denny Page wrote: > > On Mar 24, 2017, at 02:45, Miroslav Lichvar wrote: > > How common is to have link speed changing in normal operation on LAN? > > In my case, it’s currently every few minutes because I’m doing hw timestamp >

RE: Extending socket timestamping API for NTP

om>; Keller, Jacob E <jacob.e.kel...@intel.com>; Willem > de Bruijn <will...@google.com> > Subject: Re: Extending socket timestamping API for NTP > > > > On Mar 24, 2017, at 02:45, Miroslav Lichvar <mlich...@redhat.com> wrote: > > > > On Thu, Mar 23, 2

Re: Extending socket timestamping API for NTP

> On Mar 24, 2017, at 02:45, Miroslav Lichvar wrote: > > On Thu, Mar 23, 2017 at 10:08:00AM -0700, Denny Page wrote: >>> On Mar 23, 2017, at 09:21, Miroslav Lichvar wrote: >>> >>> After becoming a bit more familiar with the code I don't think this is

Re: Extending socket timestamping API for NTP

On Thu, 23 Mar 2017 10:08:00 -0700, Denny Page wrote: > I am very surprised at this. The application caching approach > requires the application retrieve the value via a system call. The > system call overhead is huge in comparison to everything else. More > importantly, the application cached

Re: Extending socket timestamping API for NTP

On Thu, Mar 23, 2017 at 10:08:00AM -0700, Denny Page wrote: > > On Mar 23, 2017, at 09:21, Miroslav Lichvar wrote: > > > > 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

Re: Extending socket timestamping API for NTP

On Thu, Mar 23, 2017 at 08:07:33PM +0100, Richard Cochran wrote: > On Thu, Mar 23, 2017 at 05:21:45PM +0100, Miroslav Lichvar wrote: > > 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

Re: Extending socket timestamping API for NTP

On Thu, Mar 23, 2017 at 05:21:45PM +0100, Miroslav Lichvar wrote: > 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.

Re: Extending socket timestamping API for NTP

[Resend as plain text for netdev] > On Mar 23, 2017, at 09:21, Miroslav Lichvar wrote: > > 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

Re: Extending socket timestamping API for NTP

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: > > On Tue, Feb 07, 2017 at 03:01:44PM +0100, Miroslav Lichvar wrote: > > > 5) new SO_TIMESTAMPING options to get transposed RX timestamps > > > > > >PTP uses

Re: Extending socket timestamping API for NTP

>> > With this change I'm getting two error messages per transmission, but >> > it looks like it may need some additional changes. >> > >> > If the first error message is received after the HW timestamp was >> > captured, >> >> When does this happen? The first timestamp is generated from >>

Re: Extending socket timestamping API for NTP

On Mon, Feb 27, 2017 at 07:01:54PM -0500, Willem de Bruijn wrote: > On Mon, Feb 27, 2017 at 10:23 AM, Miroslav Lichvar > wrote: > > On Tue, Feb 07, 2017 at 02:32:04PM -0800, Willem de Bruijn wrote: > >> >> 4) allow sockets to use both SW and HW TX timestamping at the same

Re: Extending socket timestamping API for NTP

On Mon, Feb 27, 2017 at 10:23 AM, Miroslav Lichvar wrote: > On Tue, Feb 07, 2017 at 02:32:04PM -0800, Willem de Bruijn wrote: >> >> 4) allow sockets to use both SW and HW TX timestamping at the same time >> >> >> >>When using a socket which is not bound to a specific

Re: Extending socket timestamping API for NTP

On Tue, Feb 07, 2017 at 02:32:04PM -0800, Willem de Bruijn wrote: > >> 4) allow sockets to use both SW and HW TX timestamping at the same time > >> > >>When using a socket which is not bound to a specific interface, it > >>would be nice to get transmit SW timestamps when HW timestamps are

Re: Extending socket timestamping API for NTP

> On Feb 09, 2017, at 16:33, Denny Page wrote: > > >> On Feb 09, 2017, at 11:42, sdncurious wrote: >> >> 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

Re: Extending socket timestamping API for NTP

> On Feb 09, 2017, at 11:42, sdncurious wrote: > > 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. Perhaps this will help. The specific transposition

Re: Extending socket timestamping API for NTP

> On Feb 08, 2017, at 16:45, Denny Page wrote: > > [Resend as plain text] > > >> On Feb 07, 2017, at 06:01, Miroslav Lichvar wrote: >> >> 5) new SO_TIMESTAMPING options to get transposed RX timestamps >> >> PTP uses preamble RX timestamps, but NTP

Re: Extending socket timestamping API for NTP

> On Feb 09, 2017, at 11:42, sdncurious wrote: > > 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 ? As discussed in private email, all

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

Re: Extending socket timestamping API for NTP

On Wed, Feb 08, 2017 at 04:45:05PM -0800, Denny Page wrote: > > On Feb 07, 2017, at 06:01, Miroslav Lichvar wrote: > > > > 5) new SO_TIMESTAMPING options to get transposed RX timestamps > > 6) new SO_TIMESTAMPING option to get PHC index with HW timestamps > > > > With

Re: Extending socket timestamping API for NTP

On Thu, Feb 09, 2017 at 09:02:42AM +0100, Richard Cochran wrote: > On Tue, Feb 07, 2017 at 03:01:44PM +0100, Miroslav Lichvar wrote: > > 2) new SO_TIMESTAMPING option to receive from the error queue only > >user data as was passed to sendmsg() instead of Ethernet frames > > > >Parsing

Re: Extending socket timestamping API for NTP

On Tue, Feb 07, 2017 at 03:01:44PM +0100, Miroslav Lichvar wrote: > 1) new rx_filter for NTP This is an easy one. No objections here. >Should be the current drivers of HW that can timestamp all packets >updated to fall back to HWTSTAMP_FILTER_ALL? Yes, and the phyter, the only driver

Re: Extending socket timestamping API for NTP

[Resend as plain text] > On Feb 07, 2017, at 06:01, Miroslav Lichvar 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

Re: Extending socket timestamping API for NTP

On Wed, Feb 8, 2017 at 2:26 AM, Miroslav Lichvar wrote: > On Tue, Feb 07, 2017 at 12:37:15PM -0800, sdncurious wrote: >> On Tue, Feb 7, 2017 at 6:01 AM, Miroslav Lichvar wrote: >> > 6) new SO_TIMESTAMPING option to get PHC index with HW timestamps >> >

Re: Extending socket timestamping API for NTP

Dealing with individual interfaces does not make sense. This seems to be a case where Reciprocity property is violated and hence should be handled as such. This is different than when the two sides have single but different speed NIC's. In this case the NIC used and the speed can change with each

Re: Extending socket timestamping API for NTP

> On Feb 07, 2017, at 21:27, Richard Cochran wrote: > > On Tue, Feb 07, 2017 at 05:52:52PM -0800, Denny Page wrote: >> Most, but not all. The TI DP83630 doesn’t support timestamping for all >> packets, but it does support either PTP or NTP: > > That is the one and

Re: Extending socket timestamping API for NTP

On Tue, Feb 7, 2017 at 2:32 PM, Willem de Bruijn wrote: >>> 2) new SO_TIMESTAMPING option to receive from the error queue only >>>user data as was passed to sendmsg() instead of Ethernet frames >>> >>>Parsing Ethernet and IP headers (especially IPv6

Re: Extending socket timestamping API for NTP

On Tue, Feb 07, 2017 at 12:37:15PM -0800, sdncurious wrote: > On Tue, Feb 7, 2017 at 6:01 AM, Miroslav Lichvar wrote: > > 6) new SO_TIMESTAMPING option to get PHC index with HW timestamps > > > >With bridges, bonding and other things it's difficult to determine > >

Re: Extending socket timestamping API for NTP

On Tue, Feb 07, 2017 at 10:54:22AM -0800, Soheil Hassas Yeganeh wrote: > On Tue, Feb 7, 2017 at 6:01 AM, Miroslav Lichvar wrote: > > 2) new SO_TIMESTAMPING option to receive from the error queue only > >user data as was passed to sendmsg() instead of Ethernet frames > > >

Re: Extending socket timestamping API for NTP

> On Feb 07, 2017, at 06:01, Miroslav Lichvar wrote: > > 1) new rx_filter for NTP > > Some NICs can't timestamp all received packets and are currently > unusable for NTP with HW timestamping. The new filter would allow > NTP support in new NICs and adding support to

Re: Extending socket timestamping API for NTP

On Feb 07, 2017, at 21:27, Richard Cochran wrote: > > On Tue, Feb 07, 2017 at 05:52:52PM -0800, Denny Page wrote: >> Most, but not all. The TI DP83630 doesn’t support timestamping for all >> packets, but it does support either PTP or NTP: > > That is the one and only

Re: Extending socket timestamping API for NTP

On Tue, Feb 07, 2017 at 05:52:52PM -0800, Denny Page wrote: > Most, but not all. The TI DP83630 doesn’t support timestamping for all > packets, but it does support either PTP or NTP: That is the one and only device that explicitly supports NTP. This is a nice idea, of course, but it just did not

Re: Extending socket timestamping API for NTP

[Resend without rich text] On Feb 07, 2017, at 12:17, sdncurious wrote: > 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

Re: Extending socket timestamping API for NTP

[Resend without rich text] > On Feb 07, 2017, at 09:45, Keller, Jacob E wrote: > > The main problem here is that most hardware that *can't* timestamp all > packets is pretty limited to timestamping only PTP frames. Most, but not all. The TI DP83630 doesn’t support

Re: Extending socket timestamping API for NTP

>> 2) new SO_TIMESTAMPING option to receive from the error queue only >>user data as was passed to sendmsg() instead of Ethernet frames >> >>Parsing Ethernet and IP headers (especially IPv6 options) is not >>fun and SOF_TIMESTAMPING_OPT_ID is not always practical, e.g. in >>

Re: Extending socket timestamping API for NTP

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

Re: Extending socket timestamping API for NTP

On Tue, Feb 7, 2017 at 6:01 AM, Miroslav Lichvar wrote: > 2) new SO_TIMESTAMPING option to receive from the error queue only >user data as was passed to sendmsg() instead of Ethernet frames > >Parsing Ethernet and IP headers (especially IPv6 options) is not >fun

RE: Extending socket timestamping API for NTP

ob E <jacob.e.kel...@intel.com>; Denny Page > <dennyp...@me.com>; Willem de Bruijn <will...@google.com> > Subject: Extending socket timestamping API for NTP > > I'd like to propose some changes and new options for the timestamping > interface that I think would be use

Extending socket timestamping API for NTP

I'd like to propose some changes and new options for the timestamping interface that I think would be useful for NTP implementations and maybe also other applications. Before I or someone else tries to implement them, do you think they would actually make sense and fit well in the current code?