[ntp:questions] LOCL clock reachability not 377?

Rob nomail at example.com
Tue Jul 29 17:14:31 UTC 2014


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

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).

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?

ntpd 4.2.7p444 at 1.2483-o



More information about the questions mailing list