[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7

Martin Burnicki martin.burnicki at meinberg.de
Tue Nov 26 15:22:58 UTC 2013


Brian Inglis wrote:
> On 2013-11-25 07:36, Martin Burnicki wrote:
>> Also, if you don't limit the upper bounds of the polling interval by
>> "maxpoll 6" you may run into this bug:
>>
>> NTP Bug 2341 - ntpd fails to keep up with clock drift at poll > 7
>> http://bugs.ntp.org/show_bug.cgi?id=2341
>
> Interested to see this mentioned but not seen it or reports elsewhere.
>
> This does not appear to be a problem in current stable with remote network
> servers.

The bug report is for ntp 4.2.7, i.e. the developer version, so this may 
not occur with the current stable version, which is 4.2.6p5.

As far as I I think I have seen a NTP configuration where the polling 
interval ramped up, and the control loop didn't settle anymore.

However, this may depend on the NTP software version, this may only 
happen with the Windows port only, and it may depend on whether the 
undisciplined oscillator is slow or fast, i.e. on the sign of required 
the adjustments.

> At long poll intervals, the FLL drives the frequency close to the hardware
> rate, and the offset follows down from ms to us levels.

This is probably correct as long as the oscillator is stable during the 
poll intervals. However, my observation is that usually the Windows 
system time is disciplined more accurately with short polling intervals, 
at least under Windows.

So my advice would have been to use minpoll 4 maxpoll 4, if this setting 
wouldn't affect the workaround implemented in -dev.

> With current stable and a ref clock with prefer or low poll, and backup
> servers with low or no minpoll, backup servers are polled at minpoll or
> the same rate as the ref clock, so would never see this issue.

Hm, are you really sure the polling interval for the backup server(s) 
depends on the polling interval of a configured refclock? I haven't 
noticed this, yet, but I also haven't checked this.

What if you don't have a refclock, only upstream servers?

> Could this be solved by setting poll or prefer on a ref clock, as
> recommended for best results?

As said above, I think most installations on Windows don't even have a 
refclock, so I prefer simply to add the minpoll/maxpoll parameters to 
the server line(s) specifying the upstream server(s).

> Should NTP even be expected to take care of this automatically?

If it turns out that the problem described in bug 2341 is real, then the 
best solution would be to fix this. I'd expect this is simply some kind 
of range overflow or similar, which only happens under certain conditions.

If the reason for this problem could not be located in the code then a 
workaround could be to limit maxpoll to 7 or so by default.

Anyway, in my experience everything works best under Windows if maxpoll 
is as small as possible, i.e. 6 with the restrictions implied by the 
workaround for the Windows bug.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list