> 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
>> i
[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 ta
> 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,
>>
> 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 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
[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 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 i
> 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,
> 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
[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 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
> 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 onl
[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
17 matches
Mail list logo
