In article <[EMAIL PROTECTED]>, Steve Kostecke <[EMAIL PROTECTED]> wrote: > On 2007-05-05, David Woolley <[EMAIL PROTECTED]> 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
