[ntp:questions] LOCL clock reachability not 377?

William Unruh unruh at invalid.ca
Tue Jul 29 19:46:11 UTC 2014


On 2014-07-29, A C <agcarver+ntp at acarver.net> wrote:
> 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.

Which is of course very silly, since once you get within .5 sec of the
"correct" time, pps is more than capable of keeping the system on time
(to microseconds-- it to 1000000 better than that .5 sec. It is like
Thowing out a calender because it does not indicate with millenium you
are in. 

Ie, once ATOM has been selected, it should remain selected, unless it
also gets switched of for a few hours, or there is a disagreement
between ATOM and some other selected clock source by more than a second. 


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

Is that really right? I would have expected each clock source to have
its own minpoll/maxpoll, independent of any other source. Are you sure
that is not the case?




More information about the questions mailing list