> 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
>> implementations are going to somehow
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
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 stretch
[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 Riesch) and an i210 with a 1
[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 tables. At least for 100Mb,
>> I
> 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 seems to know that the orig
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
> 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
> having a special case for th
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 is
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
> testing. :)
>
> But this
> -Original Message-
> From: Denny Page [mailto:dennyp...@me.com]
> Sent: Friday, March 24, 2017 10:18 AM
> To: Miroslav Lichvar
> Cc: Richard Cochran ; netdev@vger.kernel.org; Jiri
> Benc ; Keller, Jacob E ; Willem
> de Bruijn
> Subject: Re: Extending socket
> 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
>>> a good idea anymore :). I suspect there
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 valu
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 impact if each timest
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 co
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.
Th
[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 could trigger reading
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 pr
>> > 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
>> skb_tx_
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 time
> > Do we need a n
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 interface, it
>> >>wou
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
>
> 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 is absolutely correct.
>
> Perhaps this
> 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 is:
transposed_timesta
> 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 works with trailer RX
>> timestamps. This
> 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 hardware operates at the end
>
>> > 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
>> >
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 bridges, bonding and oth
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 Ethe
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 th
[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 need to
> transpose HW
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
>> >
>> >With bridges, bonding and other thin
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
p
> 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 device that explicitly s
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 options) is not
>>>fun and SOF_TIMES
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
> >which PHC timestamped the
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
> >
> >Parsing Ethernet
> 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 existing NICs with
>
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 device that explicitly supp
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
[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 associate the timestamp
>
[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 timestamping for all packets
>> 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
>>applicat
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 RX timestamps. The ca
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 and SOF_TIMESTAMPING_OP
Hi Miroslav,
> -Original Message-
> From: Miroslav Lichvar [mailto:mlich...@redhat.com]
> Sent: Tuesday, February 07, 2017 6:02 AM
> To: netdev@vger.kernel.org
> Cc: Richard Cochran ; Jiri Benc
> ; Keller, Jacob E ; Denny Page
> ; Willem de Bruijn
> Subject: Exten
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?
1)
47 matches
Mail list logo
