[ntp:questions] stepping and slewing

David L. Mills mills at udel.edu
Sun May 13 01:49:00 UTC 2007


The current ntpd -gq code does not set the kernel frequency from the 
frequency file, but it can be set using ntptime -f.


Serge Bets wrote:

> Hello David,
>  On Tuesday, May 8, 2007 at 19:28:22 +0100, David Woolley wrote:
>>ntpd -gq converges onto a rather better chosen estimate of the true
>>time at the same rate, but may take an extra, if trivial, 10 seconds
>>before it starts doing so. (Actually, I don't know if ntpd -gq will
>>use drift file information to predict the correction needed at the end
>>of the (including drift correction) correction period (it ought to,
>>but no one has mentioned it so far - if it does, that may be a strong
>>indication in its favour for some people));
> One of the first things done by ntpd -gq is to load the assumed good
> driftfile into the kernel frequency. Then it queries servers, gets a
> consensus offset, starts slewing this phase offset at 500 PPM, and
> immediatly quits. Some time later the slew finishes. The clock is then
> hopefully good both in phase and frequency. Nice and dandy.
> Ntpdate doesn't touch the frequency at all. It slews the phase offset,
> period. But you are free to preset the frequency via "ntptime -f", and
> get something nearer to the "ntpd -gq" level. However ntpdate constantly
> overshoots its slews, by 1/2 the offset, on purpose. This maybe helps to
> get a more centered sawtooth when repeatedly called by cron and the
> frequency is not calibrated. Otherwise these 1/2 overshoots are rather
> disturbing.
> Of course "ntpd -gq" doesn't overshoot so.
> Serge.

More information about the questions mailing list