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

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

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

Show all headers | View raw

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)?
With the former definitions it's likely that an issue is discovered earlier by monitoring IMHO.
I think an UNSYNC clock could still provide an estimated an maximum error.

Kind regards,
Ulrich Windl

> -----Original Message-----
> From: Miroslav Lichvar <mlichvar@redhat.com>
> Sent: Wednesday, July 2, 2025 4:55 PM
> 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: Delay in Switching to Stratum 16 After Local
> Reference Loss on ntpd 4.2.8p18
> 
> 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

Back to comp.protocols.time.ntp | Previous | Next — Previous 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