[ntp:questions] LOCL clock reachability not 377?

A C agcarver+ntp at acarver.net
Tue Jul 29 19:08:45 UTC 2014


On 2014-07-29 11:33, William Unruh wrote:
> On 2014-07-29, Rob <nomail at example.com> wrote:

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

ATOM always stops when the prefer peers die even if there are other
peers available but not marked prefer.  I'm still running an older
development version (4.2.7p270) that I modified to remove all the prefer
code so that the selection algorithm continues to run normally without
shutting down the ATOM driver as peers come and go.  If all the peers
die then ATOM will stop, too since there's no more selected clock.

Modifying the code also gave me the opportunity to decouple the
minpoll/maxpoll pinng that happens between the local refclocks and
external servers[1] -- the suggested configurations for many refclocks
have maxpolls that conflict to the operational etiquette for Internet
servers plus it prevents the automatic scaling of the poll time to those
servers.



[1] ATOM's own documentation suggest maxpoll of 4 to 6 to keep the clock
synced to PPS.  But that pins everything else to the same value unless a
minpoll is set on the other servers.  However, once minpoll is set, the
combination of the pinning by ATOM plus the forced required minpoll
means the external servers never change polling period nor do they get
the opportunity to start at the short 64s polling interval during
initial daemon startup and then ramp to some comfortable value in the
1000 second range.


More information about the questions mailing list