[ntp:questions] LOCL clock reachability not 377?

William Unruh unruh at invalid.ca
Tue Jul 29 18:33:14 UTC 2014


On 2014-07-29, Rob <nomail at example.com> wrote:
> I while ago I discussed the problem with an ntpd server that has to
> be synchronized to a GPSDO that provides PPS but no absolute time.
>
> After the usual discussion about "you should not want that", a solution
> was finally found using the following tricky workaround:
>
> # PPS via ATOM
> server 127.127.22.0 minpoll 4 maxpoll 4 prefer
>
> # external servers, all with prefer, to serve as reference for PPS
> server 1.2.3.4 prefer
> server 5.6.7.8 prefer
> server 9.8.7.6 prefer
>
>
> This worked OK, the time would first be synced to those 3 external
> servers and when in lock with those the PPS would be enabled and the
> time locked to that.
>
> Fine.  But now all my 3 external sources became unreachable at the
> same time, and ntpd decided that it should let the time wander away
> slowly.
>
> Of course I don't like that so I added:
>
> # local clock to continue PPS sync when all external servers fail
> server 127.127.1.0 prefer

Argh, no, never do that. Never use the the local refclock. It is useless
for almost all purposes (that there are some corner cases where it is
useful is the only reason it is there-- but it causes far more problems
than it ever has solved:-)

>
> The reasoning is that once the time is locked to PPS, it should remain
> close enough for the local clock to be trusted as an absolute time
> source (this system is rarely rebooted).

It should do that even if the external clocks disconnect. 
But I do not know if in your setup your system refuses to use the ATOM
if the external clocks disconnect-- that would be stupid, but....


>
> This appears to work OK, output from the "ntpq -p" command is now:
>
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> oPPS(0)          .PPS.            0 l   14   16  377    0.000    0.000   0.001
> *LOCAL(0)        .LOCL.           5 l   93   64    2    0.000    0.000   0.000
>  EXTERNAL SERVER .INIT.          16 u    -  256    0    0.000    0.000   0.000
>  EXTERNAL SERVER .INIT.          16 u    -  256    0    0.000    0.000   0.000
>  EXTERNAL SERVER .INIT.          16 u    -  256    0    0.000    0.000   0.000
>
> Good.
>
> But why is the "reach" of the LOCAL clock 2 and not 377?
> The reach bit cycles up until it is 0, then the LOCAL clock is no longer
> reference clock, the PPS status changes to x
>
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> xPPS(0)          .PPS.            0 l    9   16  377    0.000    0.001   0.000
>  LOCAL(0)        .LOCL.           5 l  536   64    0    0.000    0.000   0.000
>
> The next cycle the LOCAL clock starts at reach 1 again, becomes the
> reference (*), and PPS status changes to o again.
>
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> oPPS(0)          .PPS.            0 l   12   16  377    0.000    0.000   0.000
> *LOCAL(0)        .LOCL.           5 l   11   64    1    0.000    0.000   0.000
>
>
> What is the reasoning behind this?

Sounds to me like a bug.

>
> ntpd 4.2.7p444 at 1.2483-o



More information about the questions mailing list