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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
