[ntp:questions] Time reset

Andy Helten andy.helten at dot21rts.com
Thu Apr 3 22:39:31 UTC 2008

Hal Murray wrote:
>> The ntp log file shows when NTP steps the time. But then the potential harm
>> is already done. Especially if the time moves backward, our server might
>> have serious trouble. Is there a log event which indicates that the time is
>> going to be reset in order to enable us to take appropriate action before
>> the actual reset?
> I don't know of any way to get advanced warning when ntpd is about to
> step the time.
> There are command line switches to prevent stepping and to allow
> one step at startup time.
> The disadvantage with preventing steps is that it might take a long
> time to correct the time.  But if you start with good time your clock
> will never get off far enough to cause problems.
> Is there a wiki page on this topic?

Another disadvantage with preventing steps is that it isn't really a
supported mode (because it's a "tinker") and, as I've found, it doesn't
always work.  When I disable time steps on a linux 2.6.18 kernel, the
drift value goes to +/-500 and can actually swap sign from one run to
the next.  This happens even though a time step was never needed (i.e.
offset never went >128ms).  With time steps enabled the drift value
settles <90ppm (and again, no step actually occurs).

>From what I've been able to piece together, this different behavior
between step/!step is probably due to the kernel time discipline being
disabled with !step, coupled with a (potential) bug in linux that forces
NTP's "manual" adjustments to have a granularity of 1ms (i.e. somewhere
an adjustment is rounded up or down).  I've not verified the bug is
present in my 2.6.18 linux kernel, so don't quote me on it.  One might
ask why the kernel time discipline is preemptively disabled in this
manner -- maybe there is a good reason.

Our application also does not currently handle backward time steps.  Our
workaround to the problematic !step is to realize, as others on this
list have pointed out, that a time step should never occur in a normally
functioning system.  If a step does occur, we probably have bigger
problems than those caused by the step itself, such as:  lost timer
interrupts, failing hardware, runaway process, kernel bug, NTP bug, etc.


More information about the questions mailing list