Okay, I'll stick with this thread.
I plan to use "tinker step 0" to prevent step corrections on an NTP client only
host. I am only expecting large offsets in certain failure scenarios. In these
scenarios, operator intervention is required and the clock will be stepped manually as
part of a much larger procedure.
What I want to understand is how using "tinker step 0" interacts with the
kernel time discipline. Consider DM's (David Mills) 2005 post below:
In truth, the kernel is disabled only if the actual correction is
greater than 0.5 s no matter what the tinker. However, there could be
grief if the discipline switches from one to the other. There are a
rather large number of untested and probably dangerous things that
might happen with uncharted combinations of tinkers and I'm not
thrilled when spending lots of time fixing the broken combinations.
You are on your own, but a "diable kernel" command might be appropriate.
When I first read this, I thought the kernel time discipline had some sort of dependency on
step corrections being used for large errors. However, after reading David's "NTP
Clock Discipline Principles" slides describing the NHPFL, it seems like this algorithm
would be unaffected by whether or not step corrections are made. Is the concern here that
if step corrections are not made (i.e. tinker step 0), then you have untested behavior
resulting from a swtich from the daemon to the kernel discipline once the daemon discipline
brings the offset to <0.5s?
Also, DM made the following post later in the same thread:
As I said in my response to your message in my inbox, all claims on
stability are cancelled in the configuration you selected. I am not
surprised that you see large overshoots, instability and incorrect
behavior. There are all kinds of reasons for this, including violations
of the expected Unix behavior, unexpected transients between the kernel
and daemon feedback loops and who knows what else. The engineered
parameters are not designed for your application. The best choice, as I
said in my reply to your message, is to forget ntpd altogether and use
your wristwatch. You will have to analyze each and every case on your
own.
Unfortunately, I can't tell from the context here whether the "selected configuration" is the one with or without "disable
kernel" as part of it. It seems like DM is condemning the use of "tinker step 0" altogether. Is this in fact the case?
Also, I get the "unexpected transients..." comment, but not the "violations of the expected Unix behavior." What
expected Unix behavior? What violations? How would using "tinker step 0" in either configuration contribute to this?
I would also like to point out a more recent thread (http://groups.google.com/group/comp.protocols.time.ntp/browse_frm/thread/f575d212fb84384c/c4b7a8e20feff49f?lnk=st&q=tinker+step+0&rnum=7&hl=en#c4b7a8e20feff49f),
in which it seems like a bug causing the behavior originally described by Nikolaev in the Feb 2005 thread was discovered and fixed. But there is no indication that the fix was ever sourced. Does anyone know whether this was in fact a bug and if it was fixed?
Despite DM's assertion that "all claims on stability are cancelled...", I do not
understand why there is a fundamental problem with using the kernel time discipline and
"tinker step 0" together. What I'd really like is a detailed description of why this is
the case.
For starters, why is the kernel time discipline disabled when the offset is
greater than 0.5 seconds? I do appreciate your speculative response to that
question. Could someone verify whether this is in fact true?
Now on to the "unexpected transients." If a large offset is being corrected
via the daemon discipline, and then the offset gets to within 0.5 s, the kernel loop
would be started, right? This should keep moving the offset towards zero, but with the
NHPFL instead, right? Is there a concern that the offset could jump back and forth
between the 0.5 s threshold *as a result* of switching between the daemon and kernel
disciplines? Is that what DM is suggesting?
David Woolley wrote:
In article <[EMAIL PROTECTED]>,
Joe Harvell <[EMAIL PROTECTED]> 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 when "disable kernel" has been used, how is the clock frequency
adjusted? Also, why is the kernel time discipline disabled when a
By doing all the calculations in user space and periodically (every 4 seconds
on ntpd v3) calling adjtime to apply the slew correction for that second.
The result is a sawtoothing of the phase.
The kernel mode does the calculations every tick.
correction of > 0.5 seconds is required?
I suspect the limit is imposed because something in the kernel overflows.
PS. Please don't keep starting new threads for what is clearly part of
a single thread.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
