[ntp:questions] NTP.log interpretation
unruh at invalid.ca
Fri Apr 18 20:08:15 UTC 2014
On 2014-04-18, Steve Kostecke <kostecke at ntp.org> wrote:
> On 2014-04-18, William Unruh <unruh at invalid.ca> wrote:
>> On 2014-04-18, GregL <greg.leibfried at gmail.com> wrote:
>>> Now, I'm just planning on making changes to the ntp.conf, like adding
>>> the "-x" parameter. I'm hoping that that will prevent huge time
>>> resets backwards in time...should that ever be even possible again.
>> ntpd will reset the time if it is off by more than 128 ms.
> The default step threshold is 128ms. This threshold is user
> As for the '-x' option. Using it could lead to having a clock so far off
> from the correct time that ntpd will never be able to correct the offset
> via slewing.
>> Those higly non-linear jumps are one of the "features" of ntpd. If you
>> do not want them, run for example chrony. It will smoothly change the
>> time. It will however also at times slew the time much faster than
>> 500PPM to get the time back on track.
> 500PPM per day is 43 seconds per day. One could argue that a clock which
> requires more than 43 seconds per day of correction is fundamentally
> broken and requires repair rather than calibration.
If the rate error were off by that much, that would be true. However, if
the clock is off by an hour say, and you do not want it ever jump
backwards then 43 sec per day would take 100 days to correct that offset
error (assuming that none of that 43 sec per day were taken up by
rate error). At the max linux slew rate of 100000 PPM, it would take
about 10 hours to correct. Yes, your rate might be out by 10% but it may
be that never jumping is worth that to you.
Also, some clocks are just out by over 500PPM. That could be the case
for Linux with its clock calibration routine for a while (very rare but
possible). Since almost
none of us are capable of rewriting the kernel, "fixing the problem" was
not an option.
(On another bootup, the rate error could be very different.)
More information about the questions