On Sat, Feb 25, 2012 at 21:30, Richard B. Gilbert <rgilber...@comcast.net> wrote: > Get ready for a shock. NTPD needs thirty minutes or more to get a > reasonable facsimile of the correct time. To get the microseconds right, > NTPD needs more like ten hours! It's not a very good fit for running 9AM to > 5PM. You set it running and leave it running 24x7!
You might want to check your hard-earned knowledge against relatively recent improvements in ntpd startup behavior. 4.2.7p52 started introducing the new "initial offset convergence" code. 4.2.7p214 was the last refinement to the new startup code. It's already spelled out in the HTML docs, but basically ntpd startup sequence is now: 1. If there is no drift file, when the clock offset is first determined, begin a frequency calibration period lasting at least 300 seconds (actual length determined by polling interval). At the end of this, the frequency= value reported by ntpq changes from 0 to the measured value. 2. After any frequency calibration needed, begin an initial offset convergence period lasting until the offset is determined to be less than 1/2 millisecond, or for as many poll intervals as it takes to exceed 300 seconds. During this new initial offset convergence period, the frequency correction is locked at the value loaded or measured, and the offset is slewed away using a shortened time constant. 3. Once the offset or time threshold is reached, the frequency correction is unlocked and long-term operation proceeds as before. The single-minded focus on eliminating initial offset (from before ntpd was started and accumulated during frequency calibration if lacking a drift file) combined with the frequency correction lock typically results in eliminating the former ringing from startup offset elimination dragging the frequency correction notably off-target and the ensuing settling. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions