[Ntp] Re: [EXT] Re: [EXT] Re: Re: [EXT] Re: Re: [EXT] [EXT] Focussing loop detection on loop detection only.

[David Venhoek <[e-mail]>]

The mechanism is needed, because (both in ntpv4 and ntpv5) the stratum
of the server is only guaranteed to be strictly higher than that of
the "system peer", the primary time source used to synchronize the
clock. However, the clock algorithm allows other clocks to contribute
to the systems estimate of the current time through weighted
averaging. A synchronization loop through one of those secondary
sources can still cause significant clock instability, but doesn't
cause the stratum to march upwards.

A simple solution would be to require that the stratum is strictly
larger than the stratum of any source used, however that leads to
significantly larger stratum values, which leads clients to exclude
otherwise helpful sources. Therefore we need some additional solution
for doing loop detection on top of the stratum.

Kind regards,
David Venhoek

On Tue, Jul 21, 2026 at 8:52 AM Windl, Ulrich <[e-mail]> wrote:
>
> Hi!
>
> Thanks for explaining. I see. But still: Apart from the time until reaching stratum-16, is the mechanism actually needed?
> I'm looking for a case that would suffer permanently (Or at least for a long time) from absence of loop detection.
> AFAIR Dave Mills' worries were that some sub-cluster of servers may drift off, and other clients may trust that cluster. Specifically with peering being obsolete, I don't know such configuration. Anybody does?
>
> Kind regards,
> Ulrich Windl
>
> > -----Original Message-----
> > From: Miroslav Lichvar <[e-mail]>
> > Sent: Monday, July 13, 2026 10:41 AM
> > To: Hal Murray <[e-mail]>
> > Cc: Windl, Ulrich <[e-mail]>; David Venhoek <[e-mail]>;
> > NTP WG <[e-mail]>
> > Subject: [EXT] Re: [EXT] Re: [Ntp] Re: [EXT] Re: Re: [EXT] [EXT] Focussing loop
> > detection on loop detection only.
> >
> > Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR
> > gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links
> > klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die
> > Echtheit überprüft haben.
> >
> > On Fri, Jul 10, 2026 at 02:15:17AM -0700, Hal Murray wrote:
> > >
> > > Windl, Ulrich said:
> > > > I agree with the analysis, but how would loop prevention change the
> > > > situation that both servers will end up at stratum 16?
> > >
> > > It gets there faster.  A never points to B because that would make a loop.
> > >  So it jumps directly to stratum 16.  B gets to stratum 16 on its next
> > > polling.
> >
> > If loop prevention works, A will not select B if B is synchronizing to
> > A, so A should stay at stratum 3 and B at stratum 4, and their clients
> > can continue using them until their root dispersion/distance becomes
> > unacceptable.
> >
> > --
> > Miroslav Lichvar
>