[ntp:questions] Time reset
andy.helten at dot21rts.com
Fri Apr 4 02:22:44 UTC 2008
> andy.helten at 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.
More information about the questions