[ntp:questions] stepping and slewing

Serge Bets serge.bets at NOSPAM.laposte.invalid
Sat May 12 21:45:34 UTC 2007


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.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list