[ntp:questions] stepping and slewing

David Woolley david at djwhome.demon.co.uk
Sun May 6 10:43:24 UTC 2007


In article <slrnf3q5uc.cr0.kostecke at stasis.kostecke.net>,
Steve Kostecke <kostecke at ntp.isc.org> wrote:
> On 2007-05-05, David Woolley <david at djwhome.demon.co.uk> wrote:
> > Steps are instantaneous, although the daemon will sometimes take about 
> > quarter of an hour to confirm the need for them.
> 
> In my experience 'ntpd -g' + iburst will step the clock to fix a large
> offset within ~64 seconds of start-up; 'ntpq -gq' will step the clock in
> less than 30 seconds.

"Sometimes" implies "sometimes not"!  In the special case of ntpd starting,
a valid ntp.drift file being present, and the calculated offset is >128ms
the first time that at least one valid source becomes reachable, the time
is stepped immediately after that reachability event.  In all other cases,
a frequency recalibration is done and the clock isn't stepped until 900
seconds after it went outside the limits.

If the first sample is within the 128ms (theoretically, one reason for this
might be that the local clock is being used and the remote servers are 
unavailable, or didn't become reachable fast enough), a second sample that 
is outside the 128ms limit will invoke the full 900s frequency re-calibration.

If the first sample that is outside the 128ms limit is the third or subsequent
one, popcorn spike processing is invoked, and out of range samples are ignored
until the only samples in the last 900 seconds were out of range, in which 
case a step occurs and the frequency is adjusted (the latter being 
disruptive when the real problem was a change in assymmetry).

This is based on the version 4.2.0 source code.




More information about the questions mailing list