Joe,
I expect by now most folks will look at the subject line and punch the
delete key.
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.
Dave
Joe Harvell wrote:
David L. Mills wrote:
Joe,
"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?
Dave
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
(http://lists.ntp.isc.org/pipermail/questions/2005-February/004468.html)
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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
