comp.protocols.time.ntp
Affichage de l'article :
Re: Time reset

Date : Le 04 avril 2008
From : Unruh
Sujet : Re: Time reset

andy.helten@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

Posez vos questions, réponses et remarques sur les forums de FrameIP