[ntp:questions] Odd (mis)behavior when reference clock fails
martin.burnicki at meinberg.de
Tue Sep 23 07:34:06 UTC 2008
> hundoj at comcast.net (Rob Neal) writes:
>>On Tue, 16 Sep 2008, Kevin Oberman wrote:
>>> We have a fairly large "mesh" of NTP servers spread across the
>>> US. Almost all have PPS reference clocks and are quite
>>> accurate. Recently one of the reference clocks located across the county
>>> seems to have failed. Such is life.
>>> The problem is that the system's time started drifting and eventually
>>> became far enough out of sync with the mesh to be marked as a bad
>>> The only way I could get the clock to slew or step the time was to edit
>>> the configuration and comment out the reference clock and PPS. It looks
>>> like the system will only use the time from a reference clock when and
>>> if the clock is configured, even if it can't be read.
>>> Is there any way to "fix" this?
>> What is it that you consider broken? Please clarify.
>> I've re-read this several times, and don't see the problem.
>> A reference clock broke. It was disregarded because it chimed
>> You expected something different?
> A hardware clock broke. The computer which was using that hardware clock
> insisted on using that hardware clock even though it gave no time. It
> acted as a server, and eventually its time drifted so badly everyone else
> saw it as a bad chimer.
> It seems to have had other server lines in the /etc/ntp.conf, but ignored
> them in favour of a non-working refclock.
> That is how I interpret what he said, but I may be wrong as well.
This is also how I understand this.
Maybe the problem occurred because either the refclock did not report its
failure state correctly, or ntpd's refclock driver did not pass the fail
state on to the NTP kernel, so the refclock was not discarded after it
It would be helpful to know the exact NTP version, and which hardware clock
and refclock driver was used.
More information about the questions