[ntp:questions] Re: tinker step 0 (always slew) and kernel time discipline
David L. Mills
mills at udel.edu
Fri Sep 22 18:05:34 UTC 2006
I expect by now most folks will look at the subject line and punch the
For all practical purposes the step threshold, adjtime() slew rate,
kernel offset limit and daemon/kernel parameters have nothing to do with
each other. Even at large offsets the two loops can converge the time
within one hour; however, the daemon is constrained by the adjtime()
slew rate of 500 PPM and the kernel is constrained by the offset limit
of +-0.5 s. There is of course the adjtime() mods in Linux and Solaris
that make large slew adjustments unstable. This has been confirmed with
Solaris and by your observations in Linux.
Switching between the daemon and kernel disciplines is tricky because
such things as the frequency, time constant, PPS discipline, etc., have
to be matched at each switch. Avoiding steps while accepting presumably
large initial, offsets makes the extra precision available with the
kernel effectively useless anyway.
I don't handle the release process, so I don't track which little thing
that changes in the development version shows up in any particular
release. I think your other questions have been addressed in earlier posts.
Joe Harvell wrote:
> David L. Mills wrote:
>> "disable kernel" does exactly and precisely that. In that case
>> corrections are handled as if the kernel code does not exist.
>> Ordinarily, to disable the step correction also disables the kernel.
>> Your "tinker step 0" exposed a bug, now fixed, in which the kernel was
>> not automatically disabled in that case.
> In the Feb, 2005 thread, you stated that the kernel was disabled exactly
> if the amount of the correction was >0.5 seconds and hand nothing to do
> with the step threshold.
> Do you happen to know in which release of ntp the behavior was changed
> to what you are describing now?
>> Joe Harvell wrote:
>>> I have an application that is sensitive to step corrections and am
>>> considering using 'tinker step 0' to disable them altogether.
>>> However, I noticed a thread on this topic in February 2005
>>> that suggested setting 'tinker step 0' without explicitly using
>>> 'disable kernel' will essentially yield unpredictable behavior.
>>> So what does disable kernel do? Does it disable the NHPFL
>>> algorithm? Is this algorithm synonomous with the "kernel time
>>> discipline?" So when "disable kernel" has been used, how is the
>>> clock frequency adjusted? Also, why is the kernel time discipline
>>> disabled when a correction of > 0.5 seconds is required?
>>> Joe Harvell
More information about the questions