[ntp:questions] LOCL clock reachability not 377?
nomail at example.com
Tue Jul 29 18:56:29 UTC 2014
William Unruh <unruh at invalid.ca> wrote:
> 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 22.214.171.124 prefer
>> server 126.96.36.199 prefer
>> server 188.8.131.52 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
>> 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:-)
Please read the message carefully before you utter your standard comment.
As I carefully described, in this case it is useful and required.
Not because the local clock is a good idea, but because the PPS clock
in ntpd is implemented in a braindead way. This has been already discussed
the previous time.
>> 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....
I already discussed that. It is stupid, but it is how the ATOM clock
works. It uses hacks, not properly designed methods, to determine the
validity of the PPS reference. But that is not going to change, so we
need to work around it.
(by putting "prefer" on all the server lines, and apparently also by
including a local clock)
More information about the questions