|
|
comp.protocols.time.ntp
Discussion complète de l'article :
Time reset
|
Article :
27429
Date :
03-04-2008
From :
jkvbe
Sujet :
Time reset
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?
Thanks a lot,
Jan
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27430
Date :
03-04-2008
From :
Richard B. Gilbert
Sujet :
Re: Time reset
jkvbe 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?
>
> Thanks a lot,
>
> Jan
>
>
I don't know of any advance warning.
DOES the time step backward?
If ntpd is working properly it should NOT need to step the time at all
with the possible exception of a single step when ntpd is first started.
If ntpd is stepping time regularly, you have some other problem. If you
find and fix that problem, ntpd should stop stepping the time.
There are/were known issues with some Linux systems; during periods of
high disk usage, clock interrupts would be lost resulting in a FORWARD
step. AFAIK these issues were related to EIDE disks used in PIO mode
rather than DMA mode. ISTR reading that the problem has been fixed in
recent versions of Linux. YMMV
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27431
Date :
04-04-2008
From :
Hal Murray
Sujet :
Re: Time reset
>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?
--
These are my opinions, not necessarily my employer's. I hate spam.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27432
Date :
04-04-2008
From :
Unruh
Sujet :
Re: Time reset
"jkvbe" writes:
>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?
On what kind of system? HOw big a step? ntp should NOT have to step the
time except maybe when it is started up on bootup. If it steps the time.
then there is something very wrong in your system. Find out what it is.
The only log event might be to notice that the offset is say >50ms. Use
that as your warning.
>Thanks a lot,
>Jan
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27433
Date :
04-04-2008
From :
Andy Helten
Sujet :
Re: Time reset
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.
Andy
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27434
Date :
04-04-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
|
|
Article :
27435
Date :
04-04-2008
From :
Andy Helten
Sujet :
Re: Time reset
Unruh wrote:
> andy.helten@dot21rts.com (Andy Helten) writes:
>
>> 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.
>
>
Me too, but disabling time step is a tinker and tinkers are generally
use at your own risk. Besides, after much testing, I'm fairly certain
the problem is indeed with the kernel -- especially considering I did
not have this problem on an older kernel.
>> >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.
>
>
>
That is also my understanding, that the kernel does not perform the time
step but it is the kernel that updates the system time every tick. My
understanding of the kernel time discipline is that NTP sets the size of
the update to account for the system clock drift. This mechanism is
apparently disabled when time stepping is disabled. Don't ask me why.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27436
Date :
04-04-2008
From :
Hal Murray
Sujet :
Re: Time reset
>> That certainly sounds like a bug to me.
>Me too, but disabling time step is a tinker and tinkers are generally
>use at your own risk. Besides, after much testing, I'm fairly certain
>the problem is indeed with the kernel -- especially considering I did
>not have this problem on an older kernel.
What kernel version worked correctly? What version doesn't?
--
These are my opinions, not necessarily my employer's. I hate spam.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27438
Date :
04-04-2008
From :
Andy Helten
Sujet :
Re: Time reset
Hal Murray wrote:
>>> That certainly sounds like a bug to me.
>>>
>
>
>> Me too, but disabling time step is a tinker and tinkers are generally
>> use at your own risk. Besides, after much testing, I'm fairly certain
>> the problem is indeed with the kernel -- especially considering I did
>> not have this problem on an older kernel.
>>
>
> What kernel version worked correctly? What version doesn't?
>
>
Does _not_ work on RedHawk 4.2, linux 2.6.18.8:
Linux sbc1 2.6.18.8-RedHawk-4.2-trace #1 SMP PREEMPT Tue May 29 12:44:24
Does work on RedHat EL4, linux 2.6.9-5:
Linux ntp1 2.6.9-5.EL #1 Wed Jan 5 19:22:18 EST 2005 i686 i686 i386
GNU/Linux
Note that RedHawk is based on RedHat EL4 Update 4 (in other words, you
first install EL4 U4 and then install a small RedHawk upgrade).
Also note that this is not a new problem (OK, it's not that old either...):
https://lists.ntp.org/pipermail/questions/2008-March/017722.html
We plan to upgrade to the latest version of RedHawk. I'm not sure what
kernel version is in that release, but I do know it is based on RedHat EL5.
Andy
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
27439
Date :
04-04-2008
From :
David Woolley
Sujet :
Re: Time reset
Andy Helten wrote:
>
>>> offset never went >128ms). With time steps enabled the drift value
>>> settles <90ppm (and again, no step actually occurs).
90ms is a relatively bad static frequency error; a good machine will be
around 10ms. That won't help a clean cold start.
I didn't check, but did you have the default min and maxpoll values. A
high minpoll might make it difficult to get the loop to converge from
there without overflows.
>
> That is also my understanding, that the kernel does not perform the time
> step but it is the kernel that updates the system time every tick. My
> understanding of the kernel time discipline is that NTP sets the size of
The kernel time discipline is turned off if you disable steps completely
(i.e. you set the minimum error for a step to be more than half a
second or you set it to zero).
>
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
|