[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7
martin.burnicki at meinberg.de
Mon Dec 2 15:35:51 UTC 2013
David Lord wrote:
> I had maxpoll set at 10 when I first setup my network but sometimes
> at that poll rate combined with daily temperature variations offsets
> would gradually increase both in +ve and -ve directions. This could
> clearly be seen in mrtg graphs. Solution was to reduce maxpoll to 7
> or 8. I never thought of this as a bug. There was a daily variation
> depending on season and a variation due to system load.
> This has been with NetBSD 1997 to date and a period of a few years
> when running FreeBSD. Currently NetBSD-6, ntp-dev-4.2.7p401, four
> of the servers are in the pool.
I think we need to distinguish if there's a computational problem in the
code due to a rounding error, range overflow, or similar, or a
systematic problem, where ntpd is in general unable to apply adjustments
fast enough to compensate frequency drifts varying fast with temperature
Which the former can be fixed in the code once the wrong code has been
detected, the latter can only be changed by redesigning ntpd's behavior.
As far as I know long polling intervals are used preferably to increase
the accuracy of the drift measurement. For example, if you want to see
if your wrist watch goes fast or slow, you can't see this properly if
you check it once per minute. However, if you check it after one day you
see how many seconds the wrist watch has gained or lost.
However, as I understand this, this only yields proper results if the
frequency doesn't vary too much over the measurement interval.
So if ntpd only compares the time once every 1024 s the frequency may
have increased and decreased again during this interval, e.g. due to
varying CPU load, without this being noticed by ntpd. So the correction
computed in such case is probably not optimal.
From my understanding it would be better if ntpd polled in shorter
intervals to detect if the frequency drift is constant, or not. If it is
not it could decrease the polling interval to react faster on frequency
However, changing the latter would need some reengineering of the
More information about the questions