Re: [Ntp] Hard NO: Re: WGLC - draft-ietf-ntp-ntpv5-requirements

[Miroslav Lichvar <[e-mail]>]

On Tue, Dec 26, 2023 at 11:23:25PM +0000, Dave Hart wrote:
> On Thu, 14 Dec 2023 at 17:18, Miroslav Lichvar <[e-mail]> wrote:
> > If the RFC 5905 PLL+FLL is so great, why is nothing using it, not even
> > the "reference" implementation in default configuration?
> >
> 
> Would you mind elaborating how the reference implementation's PLL+FLL
> feedback loop differs from the NTPv4 spec?

The FLL frequency adjustment is calculated differently than in RFC
5905 (A.5.5.6 - local_clock). It's different in the Linux and FreeBSD
kernels (following the nanokernel implementation by David Mills) and
it's different in the "daemon loop" in ntpd. I remember David Mills
saying that the kernel and daemon loops are supposed to be different,
but neither seems to match RFC 5905.

Their responses are different from what I saw presented as designed
(e.g. in the "book"). There is significant gain peaking, which
impacts synchronization in longer chains.

If you want to see it in your own test:
- configure four hosts in local network
  - A running free (local driver or orphan mode)
  - B synchronized to A using default minpoll and maxpoll
  - C synchronized to B using default minpoll and maxpoll
  - D synchronized to C using default minpoll and maxpoll
- configure B, C, D to also poll A at minpoll and maxpoll of 3 with
  the noselect option
- let it settle down and reach the maximum poll (at least 10 hours)
- make a 10 ms step on A (e.g. date -s '-0.01 sec' on Linux)
- let it run for 40 hours
- plot the offsets measured by B, C, D against A

You should see the peaks getting significantly larger with increasing
stratum and possibly also some oscillations growing in time, but there
is some luck required.

> If verified that would seem to me a reason to improve the algorithms,
> rather than decide it's time for a wild west where every NTP implementation
> is free to behave in any way, as that would invite pathological results in
> situations where differing implementations sit on the synchronization path
> between the reference clock and the ultimate client.

There is no algorithm that can work optimally in all conditions. The
server doesn't know how many clients it has at different strata, how
stable are their clocks and in what network conditions they operate,
to even be able to consider optimizing its response for a subset of
its clients.

You can improve ntpd to work better in the conditions you consider
important, but please don't try to force your solution on others.
They likely have very different requirements.

> > Nobody seems to care. Maybe
> > it's a bug, but after so many years I think we can conclude that
> > Internet will not break if all NTP implementations don't have the
> > "well defined" response.
> >
> 
> The internet will not break even if all NTP sources were only good to a few
> seconds.  Those who require tight sync (such as distributed databases)
> engineer solutions to meet their requirements.

Ok, so you seem to agree that using one set of algorithms is not
critical for synchronization over the Internet between different
implementations.

The point I was trying to make is that ntpd without the "well defined
response" of RFC 5905 apparently worked well enough for many years
that its maintainers and users didn't notice any problems, which I
think confirms that it is not that important that it would have to be
prescribed in the NTPv5 spec.

-- 
Miroslav Lichvar