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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
