[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