[ntp:questions] Re: Ref clocks and polling intervals
chris at loopy.oak-wood.co.uk
Thu Nov 25 08:58:50 UTC 2004
In message <co31cd$st3$1 at dewey.udel.edu>, David L. Mills
<mills at udel.edu> writes
>The reference clock poll interval is not intended to increase unless
>you tell it to. That might be a bug; I'll look into it.
For clarity, it isn't doing. The original problem was that all poll
intervals stayed at 64s. It seems you released a development version
that addressed this by not tying the system maxpoll to the reference
So with this version the ref clock stays polling at 64s and everything
else rises to 1024s. But the rate at which the PLL frequency is adjusted
drops dramatically, and this, I think, is what is leading to the diurnal
swings. As the room temperature changes there is a lag before the PLL
frequency adjusts to compensate.
>However, just about all the machines around here loaf at 1024 s without
>swinging more than a couple of milliseconds. If yours are much greater
>than that, including the reference clock, something else might be going
Actually the swings aren't that great, just a lot bigger than they were
before. Perhaps I've been spoilt.
>Set the maxpoll for the reference clock to 6 and leave the others
>alone. You should see the same behavior as I.
I'm pretty sure that with the version I'm using, setting the ref clock
maxpoll to 6 will bring all the other poll intervals down. Which was the
point of my question really.
Can I set the refclock maxpoll to 6 and then explicitly set the others
And what about using tinker maxpoll so that I don't have to explicitly
set values for other servers?
Here's the mail, apparently from you Dave, that I was recently
>>>From David L Mills 30-Nov-2003:
> There have been discussions that ntpd does not increase the poll
> interval for other than reference clocks when reference clocks are in
> synch. Turns out there was a trivial reason for this, but that exposed a
> wider set of issues and a possibility for performance improvement.
> The reason the poll interval did not increase was very simple. The
> maxpoll for reference clocks was set to minpoll and the system poll
> interval was clamped to the maxpoll. As there is no good reason for
> this, I set the maxpoll to the default and set hpoll for reference
> clocks to minpoll, so the default behavior is unchanged. However, the
> system poll interval now works just like nonreference clocks.
> The result is that the loop bandwidth narrows by a factor of 16 as the
> system poll approaches 1024 s and that had an interesting side effect.
> Since the reference clocks are now oversampled by that factor, the
> frequency discipline gets stiff as a board while the phase wiggles got
> nipped at the higher poll rate. The result is a considerable improvement
> in performance with reference clocks, where the residual jitter and
> offsets are down to the 10-20 us level even without PPS steering. See
> pogo for demonstration.
> The possible downside of the narrow bandwidth may be an increased
> sensitivity to frequency (temperature) surges. I'm testing this here on
> a number of machines with varying servers both here and elsewhere. What
> I need is a couple guys with good clocks to try in their own
> The exercise turned up a number of minor statistics nits leading to
> separate estimators for system error and clock discipline jitter, which
> should improve the poll-adjust algorithm.
> You can always revert to the old algorithm by setting maxpoll for the
> reference clock to minpoll. For this reason, it is better not to try to
> "improve things" by setting maxpoll to 4 for the atom driver.
> The new stuff is at ntp-dev and also at
More information about the questions