[ntp:questions] Time reset

Unruh 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.

Yup.


>Andy




More information about the questions mailing list