On 2011-07-06, Chris Albertson <[email protected]> wrote: > On Wed, Jul 6, 2011 at 2:59 PM, David Woolley ><[email protected]> wrote: > >>> I found it. >>> http://www.eecis.udel.edu/~mills/ntp/html/clock.html > >> For a persistent offset of more than 128ms, ntpd will remove the whole >> offset in one go. This will be after the 15 minute delay and subsequently >> finding multiple samples showing an acceptably low jitter. > > So what did I miss when I read the above link?
Where in this does it state that steps are only 125ms ? | Step and Stepout Thresholds | | Under ordinary conditions, the clock discipline gradually slews the | clock to the correct time, so that the time is effectively continuous | and never stepped forward pr backward. If, due to extreme network | congestion, an offset spike exceeds the step threshold, the spike is | discarded. However, if offset spikes greater than the step threshold | persist for an interval more than the stepout threshold, the system | clock is stepped to the correct time. In practice, the need for a step | has been extremely rare and almost always the result of a hardware | failure or operator error. The step threshold and stepout thresholds | default to 125 ms and 300 s, respective, but can be changed with the | step and stepout options of the tinker command, respectively. If the | step threshold is set to zero, the step function is entirely disabled | and the clock is always slewed. The daemon sets the step threshold to | 600 s using the -x option on the command line. If the -g option is used | or the step threshold is set greater than 0.5 s, the precision time | kernel support is disabled. [snip: 2 paragraphs which don't discuss the threshold] -- Steve Kostecke <[email protected]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
