[ntp:questions] ntpd wedged again

A C agcarver+ntp at acarver.net
Thu Feb 16 06:11:04 UTC 2012

On 2/15/2012 21:36, Michael Deutschmann wrote:
> On Mon, 13 Feb 2012, A C wrote:
>> I'm not sure it's a good idea either but I would really like to
>> understand why a refclock clamps the polling interval at such a low
>> value when nearly every bit of documentation says we should be kind to
>> NTP servers and make sure the polling period is allowed to reach 1024.
> I think the explanation was that, if your server is polling its
> reference every 64s and the internet every 1024s, then should the
> reference go *crazy*, it has 15 polls to wreck the system time before
> the daemon notices that all three internet backups reject the decision
> already taken to speed up/slow down the system clock drastically.
> In contrast, with everything at 64s, the falseticking reference's
> signals are taken together with the internet opinion, and rejected
> before they do damage.  Things smoothly degrade into the internet-only
> situation.
> Although I see two problems with this logic.  For one, I don't see how
> you can prevent an excursion when faced with a falseticking PPS.  For
> another, this assumes it is likely that a reference clock might actually
> go crazy, as opposed to merely failing cleanly in such a way that the
> NTP code is fed "Sorry, I'm not sure anymore" rather than lies.

Your explanation seems reasonable, trying to maintain sanity with all 
the clocks staying at the same update period.  I would also agree with 
your concerns.  It seems that if the source fails, it fails 
catastrophically and ntpd knows it.  For example, a GPS just stops 
reporting or slips way out of sync in short order.  I'll toy with it 
some more but I'm waiting for my test to complete and don't want to 
restart ntpd yet.  I need to give it 10 days to see if it keeps running 
or dies.

More information about the questions mailing list