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

[David Venhoek <[e-mail]>]

Hi All,

>From my perspective, the fact that apparently (at least as harlan
seems to claim in his original email) the algorithm specified in
RFC5905 is fragile would be all the more reason to not specify it as
"the standard". If this is really the case, we should rather be
looking harder for solutions that are more resilient and not so
sensitive to

I've done enough experiments with real hardware and over the internet
to have realized that pretty much any noise profile that you could
imagine will exist somewhere. I've seen clocks showing 24 hour phase
oscillations due to temperature oscillations, as well as clocks that
had similar cycles but shorter due to a course-controlling ac system.
Over the internet, there are also connections with "interesting"
(read, hella anoying to deal with) patterns in their latency, from
weekly patterns to daily patterns and even some 1.5 hour pattern stuff
that I am not really understanding where it comes from. And honestly,
once I get to the point of looking at the 1-1000hz noise range in the
ptp implementation I am currently working on, I wouldn't be surprised
to at least find something related to the power grid and it's
idiosyncracies.

Yes, another algorithm may introduce a new noise pattern, but given
the very wide amount of variation that is already out there it is
unlikely to.

Looking at the current moment, we are now in a situation where there
are 3 algorithms operating in the space, with the one in the
"reference" implementation, the one from chrony and the one from
ntpd-rs. I have personally not seen any indication of problems caused
by this, rather the oposite. From measurements it looks very likely
that both chrony and ntpd-rs are capable of, with similar poll
intervals, synchronizing to about an order of magnitude larger
precision.

And it is this precision that seems to me at least the thing that end
users want. Both legal (i.e. for trading firms the requirement that
clocks are to be within 30us from UTC) as well as practical
applications typically have just an upper bound of the clock must not
be more than x seconds from a reference.

Given all this, strictly mandating an algorithm that is both fragile
and imprecise seems like exactly the opposite from what we should
want.

As for the discussion on differences between RFC5905 and the
"reference" implementation, I don't have concrete differences
(unfortunately). However, we had a lot of trouble with its performance
back when we did have it implemented in ntpd-rs, also compared to the
"reference" implementation. Part of this may have been due to bugs on
our end, but it wouldn't surprise me if there are further differences.

Also, the fact that David L Mills apparantly had the tendency to just
change the algorithm without changes to the standard at least on the
surface feels also just wrong to me. That gives a lot of vibes of
"innovation, but only by us" from the "reference" implementation
people, which is I think highly harmful. I sincerely hope that that is
just a wrong impression from my side.

Kind regards,
David Venhoek

On Wed, Dec 27, 2023 at 8:22 AM Harlan Stenn <[e-mail]> wrote:
>
> On 12/26/2023 3:23 PM, Dave Hart wrote:
> > On Thu, 14 Dec 2023 at 17:18, Miroslav Lichvar <[e-mail]
> > <mailto:[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.
>
> Or better describe the conditions for these problems?
>
> If you are saying that the default config can show oscillations as poll
> intervals increase, all I can say is we haven't seen reports of this.
>
> If we had, we'd be taking steps to fix it.
>
> If you have seen this, perhaps you'd be kind enough to post about how
> one might change the default values to ones more suitable for longer
> poll intervals, or even telling us how to demonstrate the problem.
>
> >     which can be sometimes seen
> >     even on monitoring graphs of pool.ntp.org <http://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.
>
> I'm negatively impressed with your conclusion, Miroslav.
>
> "The Internet" probably won't break, because "the internet" doesn't
> exchange time that way, and I would bet that you know this.
>
> A single machine will either have a crafted config file, well-tended or
> not, and static or pool servers.  How well do you think the vast
> majority of these machines are monitored to see if there are problems?
> How badly would they have to screw up to be noticed?
>
> If somebody bothers to look and sees one of the hosts in their static
> config file is bad, they will likely just throw out the bad site and
> replace it.
>
> If they are using the "pool" directive and there are misbehaving servers
> *that otherwise survive the pool monitoring service* then ntpd will
> notice the bad performers and throw them out automatically.
>
> In an enterprise, the odds are quite high that time for the enterprise
> is sync'd from a set of curated machines.  These machines are likely
> getting their time from reliable sources.  They won't be talking to
> poorly-behaving time sources.  This translates to the (internal)
> machines that get their time from the (well-behaved/reliable) internal
> time sources.
>
> So sure, the stuff the NTP Project has put out there is very resilient
> and well-behaved.  There's a good chance it will continue to behave well
> even in an increasingly hostile environment.
>
> But why would any <positive-intentioned> person want to take steps to
> increase the environment's hostility?
>
> As I have said before, the world of time-synchronization is not the
> place to use creative destruction as a method to promote evolution.
>
> > Cheers,
> > Dave Hart
> >
> >
> > _______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
>
> --
> Harlan Stenn <[e-mail]>
> http://networktimefoundation.org - be a member!
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp