Menu
ntp doesn't want to jump your clock, because discontinuous time jumps are Bad. It wants to adjust your clock gradually -- very gradually. It's very conservative: by default, it won't slew your clock by more than xx parts per million (ppm).
But since ntp is so conservative, if it finds out that your clock is too far off, such that adjusting it gradually would take forever, it will fall back and jump your clock anyway (even though that's Bad). It does this, by default, if it would take longer than yy hours to adjust your clock gradually.
If you want, you can tell ntp to adjust your clock faster (i.e. less gradually), up to a maximum of zz ppm.
My question is, what are xx, yy, and zz? I know those thresholds exist, I'm pretty sure they're documented, I'm pretty sure they're configurable, but I can never remember the values and I can never find them.
If you know what they are, ideally I'd like to know (a) what the default values are and (b) where they're documented and (c) how they can be configured and (d) where the actual code is that makes the decision to slew or jump. Thanks.
914
Apr 29, 2007, 9:25:23 PM4/29/07. to. Slewing means that ntpd adjusts the clock at a maximum rate of 500. microseconds per second.
Re: NTP - Atomic Clock - Time Going Backwards ? Because NTP (al least when you use slewing - and you should) does not adjust time backwards. It does slow your clock ticks down until actual time 'catches up' and then the clocks run normally.
Offset: Offset generally refers to the difference in time between an external timing reference and time on a local machine. The greater the offset, the more inaccurate the timing source is. Synchronised NTP servers will generally have a low offset. Offset is generally measured in milliseconds.
NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions. Asymmetric routes and network congestion can cause errors of 100 ms or more.
xx: 128ms
The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s.
I don't know of a way to change xx.
yy: 600s
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 threshold can be changed using 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.
zz : 500ppm
The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range.
I don't believe there is a way to change zz.
As for actual code that shows how the decision is made to slew/step, you probably won't find it online. Only the algorithm. Here and here are great links on that algorithm works.
132
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
