[ntp:questions] Time reset
unruh-spam at physics.ubc.ca
Fri Apr 4 01:00:33 UTC 2008
andy.helten at dot21rts.com (Andy Helten) writes:
>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).
That certainly sounds like a bug to me.
>>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.
AFAIK it is not the kernel that does the time step. Ie, the kernel
discipline is not what demands the step. Also, adjtime certainly does not
have a 1ms granularity.
>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