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]

Date:   Mon, 27 Mar 2017 09:25:03 -0700
From:   Denny Page <dennypage@...com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Miroslav Lichvar <mlichvar@...hat.com>, netdev@...r.kernel.org,
        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 Mar 27, 2017, at 07:29, Richard Cochran <richardcochran@...il.com> 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 the igb is even more work for the app.

If you are doing correction in the application, _every_ driver is a special case. The a driver making average (known) correction is no more special than any other.

> In addition, if you look into the igb data sheet, you will find a
> range of correction values, with little indication of how they
> measured the latency and what the ranges depend on.

You are looking at the 2.2 datasheet I expect. The values for 10Mb and 1Gb have been removed from subsequent datasheets, however they have added a bit more detail as to how the values are measured and what the values.

> In my
> experiments, I have seen the igb consistently land on the extreme of
> one of the ranges (who knows why), but the driver corrects using the
> average, forcing me then to correct the remaining offset by hand.

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 the i210 and i211 at both 100Mb and 1Gb. The “external link partner” numbers Intel currently publishes for the 100Mb appear accurate. I’m still finalizing the values for 1Gb, but one thing I will note is that the values for master mode and slave mode are quite different. FWIW, master/slave mode correction is also something that can only be corrected in the driver :)

I am curious to know any data you developed in your experiments and how you did the measurements. Please email me directly if you are willing to share.

Thanks,
Denny