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-next>] [day] [month] [year] [list]

Date:   Fri, 24 Mar 2017 10:45:30 +0100
From:   Miroslav Lichvar <mlichvar@...hat.com>
To:     Denny Page <dennypage@...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 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?

There are other problems with changing link speed. It does not affect
only the transposition.

- If the change happens during a measurement, anywhere on the path
  between the server and client, the measured offset will have an
  error due to the asymmetry in the network delay. An NTP measurement
  in the basic mode is short (it's just the rount-trip time), so it's
  not very likely to be hit by a link speed change, but in the
  interleaved mode the probability is exactly the opposite.

- Even if the measurement is not hit and the measured offset is
  accurate, the change in the measured delay may confuse the NTP
  client (e.g. temporarily disrupt its sample filtering).

- The TX/RX compensation values depend on the link speed. If the
  application doesn't reliably know link speed for each packet, the
  compensation cannot be reliable either.

It seems to me for best timekeeping with NTP it is necessary to make
sure the link speed in the network is constant, even if the
transposition was always accurate.

-- 
Miroslav Lichvar