Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.protocols.time.ntp > #164197

Re: [EXT] Re: Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18

From "Miroslav Lichvar via questions Mailing List" <questions@lists.ntp.org>
Newsgroups comp.protocols.time.ntp
Subject Re: [EXT] Re: Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18
Date 2025-07-07 09:38 +0000
Organization Taughannock Networks, Trumansburg NY
Message-ID <aGuUd-UE2_quWNi4@localhost> (permalink)
References (5 earlier) <CAMbSiYAfxWmzdx494b5AWNGnfbFwCL7NfZnjMy0jxjY7GpTC_w@mail.gmail.com> <aGT-5oBONitTpxU3@localhost> <f5ff0fc9703e414b999c5845039667fa@ukr.de> <1040f45$2qa5k$1@dont-email.me> <CAD9nGEw-FxVp4YhonS2XNLACfDY0BfJ4ZMsNie0LVsHTqXq1vQ@mail.gmail.com>

Show all headers | View raw

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

Back to comp.protocols.time.ntp | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 "Harlan Stenn via questions Mailing List" <questions@lists.ntp.org> - 2025-07-01 03:48 +0000
  Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 Miroslav Lichvar <mlichvar@redhat.com> - 2025-07-01 11:00 +0000
    RE: [EXT] Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 "Windl, Ulrich" <u.windl@ukr.de> - 2025-07-02 10:23 +0000
      Re: [EXT] Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 "Miroslav Lichvar via questions Mailing List" <questions@lists.ntp.org> - 2025-07-02 14:58 +0000
        RE: [EXT] Re: Re: Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 "Windl, Ulrich" <u.windl@ukr.de> - 2025-07-07 10:58 +0000
    Re: [EXT] Re: Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 "Miroslav Lichvar via questions Mailing List" <questions@lists.ntp.org> - 2025-07-07 09:38 +0000
  Re: [EXT] Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 "Miroslav Lichvar via questions Mailing List" <questions@lists.ntp.org> - 2025-07-02 10:43 +0000
    RE: [EXT] Re: Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18 "Windl, Ulrich" <u.windl@ukr.de> - 2025-07-04 17:08 +0000

csiph-web