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

[Dave Hart <[e-mail]>]

On Thu, 14 Dec 2023 at 17:18, Miroslav Lichvar <[e-mail]> wrote:

> On Thu, Dec 14, 2023 at 03:16:29AM -0800, Harlan Stenn wrote:
> > The core "mission" of NTP is time synchronization with a (well) defined
> > response to a "time impulse".  This is the reason why previous NTP
> > specifications have included the algorithms.  Prof. Mills and some others
> > have done a LOT of testing to ensure reliable and predictable behavior of
> > time synchronization, in the "normal" and "time impulse" cases over a
> very
> > wide range of circumstances.
>
> 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?  I'm not aware of any
intentional deviation, but Dr. Mills wasn't shy about making changes to the
implementation that he felt was an improvement before documenting it in
another RFC.

ntpd in default configuration has a poor response with longer polling
> intervals. It suffers from oscillations,


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.


> which can be sometimes seen
> even on monitoring graphs of pool.ntp.org.


That public pool uses primitive monitoring that does not take into account
the delay or jitter between the monitoring station and the server.
Moreover, the requirements for participating are very lenient, allowing
clocks that appear to be up to 70ms off of UTC.  That pool is therefore not
a good example of a well-engineered and well-maintained
synchronization source.  It's fine to get the clock within a few hundred
milliseconds, but stricter requirements call for a more precise source and
better error budgeting.


> 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.

Cheers,
Dave Hart