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

unruh unruh at invalid.ca
Mon Dec 2 18:05:27 UTC 2013

On 2013-12-02, Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> 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 
> changes.

ntp has never been good at handling drift changes due to things like
temperature. It has always been a weakness. But those are only at the
<1PPM level, and that in general does not cause great fluctuations in the
time.  So if the fluctuations are at the ms level, it is something else
doing it. 

> 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 

Primarily because the ntpd algorithm has no memory. It cannot use
consistant past behaviour to predict the future. 

> 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 

Sure you can as long as you remember what the readings were for more
than a minute. 

> 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.

It is made worse by the fact that ntpd throws out 7 out of 8
measurements due to the filtering.

>  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 
> changes.
> However, changing the latter would need some reengineering of the 
> control loop.

Good luck in that area. Note that chrony has a very different control
loop than ntpd does, and also does better on control of the clock. 

> Martin

More information about the questions mailing list