[ntp:hackers] A wee experiment

David L. Mills mills at udel.edu
Sun Nov 30 20:39:52 PST 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 hackers mailing list