From Newsgroup: comp.protocols.time.ntp

Hi!

Well things seems a bit more complex:
The kernel clock has a clock state, too: Initially after boot it is unsynchronized, but when NTP updates the clock, it will be set to synchronizes, together with a few more parameters.
When the maximum error (the kernel clock advances automatically) reaches a threshold, the clock is set to unsynchronized again. So even if NTP crashes, the kernel clock may indicate a synchronized status for some time.
In contrast when NTP is considering itself UNSNC, will it set the kernel clock to unsynchronized immediately, or will it just stop sending updates to the kernel clock?
As I understood the discussion so far, the latter is the case.
What's not quite clear at the moment is whether NTP ever reads back the values provided from the kernel clock.

Traditionally NTP was assumed to know everything about the kernel clock, but maybe today the kernel clock knows its properties better than a generic NTP will, right?
So I think the interface between the NTP clock model and the kernel clock should be explained a bit better in the upcoming specification.
As I understand it , the NTP kernel clock model is optional, still.

Kind regards,
Ulrich Windl

-----Original Message-----
From: Miroslav Lichvar <mlichvar@redhat.com>
Sent: Monday, July 7, 2025 11:34 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: 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 Fri, Jul 04, 2025 at 06:54:13AM +0000, Windl, Ulrich wrote:

Well,

We could start a discussion what "UNSYNC" really means:
Does it mean the clock is free-running (not updated by the clock discipline),

or does it mean the clock's estimated offset is "just terrible" (like 16 seconds)?

I think in the context of the clock_select() function it means there
is no source selected and the clock cannot be updated. The selection
itself doesn't change the status of the clock. If it was previously considered to be synchronized, it will still be synchronized.

With the former definitions it's likely that an issue is discovered earlier by

monitoring IMHO.

The monitoring can check the reachability directly and discover the
issue even sooner, no need to wait for the orphan timeout to activate
after the source becomes unreachable.

--
Miroslav Lichvar

--- Synchronet 3.21a-Linux NewsLink 1.2