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]

Message-id: <89CFCD8E-1A58-48C5-9D6E-99695502CFD9@me.com>
Date:   Fri, 24 Mar 2017 10:17:51 -0700
From:   Denny Page <dennypage@...com>
To:     Miroslav Lichvar <mlichvar@...hat.com>
Cc:     Richard Cochran <richardcochran@...il.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 24, 2017, at 02:45, Miroslav Lichvar <mlichvar@...hat.com> wrote:
> 
> On Thu, Mar 23, 2017 at 10:08:00AM -0700, Denny Page wrote:
>>> On Mar 23, 2017, at 09:21, Miroslav Lichvar <mlichvar@...hat.com> 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 of
>>> the current link speed. If the value had to be cached it would make
>>> more sense to do it in the application.
>> 
>> 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 value may be wrong. If the application takes a sample every 5 seconds, there are 5 seconds of timestamps that can be wildly wrong.
> 
> I'm just trying to be practical and minimize the performance impact
> and the amount of code that needs to be written, reviewed and
> maintained.
> 
> 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 does speak to my point. If it’s cached by the application, the application has to check it regularly to minimize the possibility of bad timestamps. If the link speed doesn’t change, every call by the application is wasted overhead. If it’s cached by the driver, there is no waste, and the stamps are always correct.

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. It appears that all Intel drivers are caching link speed. I looked at a few other popular manufacturers, and it appears that caching link speed is common. The only one I quickly found that didn’t cache was realtek.

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.