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 16:29:25 +0200
From:   Richard Cochran <richardcochran@...il.com>
To:     Miroslav Lichvar <mlichvar@...hat.com>
Cc:     Denny Page <dennypage@...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 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 also performing timestamp correction based on that link speed.
> 
> Isn't the i210 the only NIC for which the correction is actually
> implemented?

Yes.

> Will this ever be done for all HW with timestamping
> support, so that the applications wouldn't have to care about link
> speed?

No.

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.

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.  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 believe that timestamp correction, whether it be speed based latency, header -> trailer, or whatever else might be needed later down the line, are properly done in the driver. It’s a lot for the application to try and figure out if it should or should not be doing corrections and what correction to apply. The driver knows.
> 
> I agree, but I'm not sure how feasible that is.

+1

Thanks,
Richard