[ntp:questions] Re: Ref clocks and polling intervals

David L. Mills mills at udel.edu
Fri Nov 26 04:22:07 UTC 2004


It's more complicated than that. The clock discipline algorithm takes 
updates from the combined set of truechimer servers, then uses the 
measured jitter (time differences) and wander (frequency differences) to 
establish the Allan intercept, which may be above or below the current 
poll interval. It then steers toward the intercept, but clamped from 
above and below by the minpoll and maxpoll of the selected system peer. 
Whatever the system poll interval turns out to be, this value is 
included in the NTP packets sent by the server.

In order to protect the network, clients of the server will not use a 
poll interval less than the server poll interval included in the packet. 
So, as the server system poll interval ramps up, so do the clients and 
that is how the algorithm works now, both in ordinary servers and in 
reference clocks.

What happened recently is the addition of the modem driver, which of 
necessity must limit the telephone call frequency. This is done 
automatically by placing a call at each poll interval and allowing the 
poll interval to naturally ramp up to maxpoll. For instance, setting 
minpoll to 12 and maxpoll to 17 keeps the call interval not less than 
about 1.5 hours to 1.5 days. This works well in the current design.

The problem is, at least one and possibly other reference clock drivers 
have to do something if they do not want to increase the poll interval 
as determined by the clock discipline algorithm. It is vital to 
understand that there is very little benefit in reducing the driver poll 
interval less than the system poll interval. The discipline loop is 
already stiff as a board and oversampling will not result in much 
benefit, but on the other hand it won't do harm. But, when you set 
maxpoll for the radio to 64 you clamped the system poll interval to that 
value and, with obedience to the specification, this forces the clients 
to clamp to that value as well.

Having said that, the reason you would want to oversample anyway is to 
retrieve the status bits, error codes and reachability indications more 
often than once every 1024 s, even if the system poll interval rises to 
that value. Many drivers have no problem with this, as they poll the 
radio itself using means other than the system poll interval. The reason 
for this is to take frequent samples to fill up the median filter, so 
the filter algorithm can groom the samples and reduce serial port jitter.

As for the present situation, I'll devise a workaround which will allow 
some drivers to respect the system poll interval and others to force the 
poll at minpoll.


Chris Hastie wrote:
> 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
> clock's.
> 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
> to 10?
> 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
> forwarded:
>>>>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 mailing list