[ntp:questions] Frequency Offset

Dave Hart hart at ntp.org
Sun Feb 26 05:00:47 UTC 2012


On Sat, Feb 25, 2012 at 21:30, Richard B. Gilbert
<rgilbert88 at 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


More information about the questions mailing list