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

Martin Burnicki martin.burnicki at meinberg.de
Mon Dec 9 15:55:50 UTC 2013


David Woolley wrote:
> On 02/12/13 15:35, Martin Burnicki wrote:
>
>>  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.
>
> It already oversamples and adjusts the poll rate if the frequency
> stability is poor.

I know this is the case, at least in theory.

However, here are some plots of loopstats from a Windows machine with a 
single upstream server configured. These graphs also include log2 of the 
current polling interval. First configuration is just

server aa.bb.cc.dd iburst

i.e. polling intervals not clamped:
http://support.ntp.org/people/burnicki/windows/ntpd-4.2.6p5-WinXP-no_poll_limit.pdf

As can be seen, as soon as ntpd assumes the clock drift is stable the 
polling interval is ramped up. After some time ntpd detects that the 
offset has increased and decreases the polling  interval to get the 
filter settled again. Then the same game starts over.

In the next configuration the polling interval has been clamped to 6, 
i.e. the configuration line reads:

server aa.bb.cc.dd iburst mipoll 6 maxpoll 6

Here's the graph, taken over the same time interval, plotted with same 
scale ranges:
http://support.ntp.org/people/burnicki/windows/ntpd-4.2.6p5-WinXP-poll_6.pdf

You can see that the performance with the fixed small polling interval 
is much better. I don't know a single customer who would prefer the 
first solution since in theory it's better than the second one, though 
in practice this is not the case.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list