Serge, The current ntpd -gq code does not set the kernel frequency from the frequency file, but it can be set using ntptime -f.
Dave 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
