From Newsgroup: comp.protocols.time.ntp

Miroslav,

from the RFC citations found in the bug report it seems to be specified differently, or I misunderstood.

Kind regards,
Ulrich Windl

-----Original Message-----
From: Miroslav Lichvar <mlichvar@redhat.com>
Sent: Wednesday, July 2, 2025 11:42 AM
To: Windl, Ulrich <u.windl@ukr.de>
Cc: Dave Hart <davehart@gmail.com>; questions@lists.ntp.org; J|+rgen Perlinger <juergen.perlinger@t-online.de>; J|+rgen Perlinger <perlinger@ntp.org>; Windl, Ulrich <windl@ntp.org>
Subject: [EXT] Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18

Sicherheits-Hinweis: Diese E-Mail wurde von einer Person au|ferhalb des
UKR gesendet. Seien Sie vorsichtig vor gef|nlschten Absendern, wenn Sie auf Links klicken, Anh|nnge ||ffnen oder weitere Aktionen ausf|+hren, bevor Sie die Echtheit |+berpr|+ft haben.

On Wed, Jul 02, 2025 at 09:23:12AM +0000, Windl, Ulrich wrote:

Actually, I had completely forgotten about that issue. Reading it again, it

seems stratum should be 16 if all sources are unreachable (lost).

Why should it do that?

The idea in NTPv4 is that the decision if a source is acceptable
should be made on the client side. If a server loses all time sources,
its root dispersion will grow (15 ppm by default). If a client of that
server has other sources, it can reselect when the distance becomes
larger than that of the other sources.

If the server quickly switches to the unsynchronized state (as recent
ntpd versions seem to be doing), the client can no longer synchronize
to it, even if it has no other sources available. If there are
multiple clients of that server, their clocks will not stay in sync,
each will be drifting on its own.

--
Miroslav Lichvar

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Wed, Jul 02, 2025 at 09:50:37AM +0000, Windl, Ulrich wrote:

Miroslav,

from the RFC citations found in the bug report it seems to be specified differently, or I misunderstood.

If you are referring to the Figure 24 of RFC 5905, which has "return
(UNSYNC)" for this path, there doesn't seem to be anything suggesting
that should be handled by resetting the clock to an unsynchronized
state.

The clock_select() function in A.5.5.1 doesn't have a return value and
in this case when no usable sources are present it doesn't do
anything, it just returns.

/*
* There must be at least NSANE survivors to satisfy the
* correctness assertions. Ordinarily, the Byzantine criteria
* require four survivors, but for the demonstration here, one
* is acceptable.
*/
if (s.n < NSANE)
return;
--
Miroslav Lichvar

--- Synchronet 3.21d-Linux NewsLink 1.2