Guys,
Every few months I have to remind the group about the laws of physics
and the evils of implementation. First, the ntpd discipline algorithm
described in various documents and the book is basically a linear,
type-II phase-lock loop with characteristics carefully tailored for
optimum response. In principle, there is no limitation on the step
threshold or even if it is disabled. However, there are gotchas:
1. The original Unix adjtime() function uses a constant slew rate of 500
PPM. This results in very long convergence times for a large initial
offset of several seconds or more.
2. In an apparently misguided attempt to "fix" this problem, Linux (and
Solaris) added variable slew feature to adjtime(). This creates an extra
poll in the discipline loop resulting in unstable behavior, especially
with initial offsets of a second or more.
3. The reason for the 0.5 second limitation in the kernel code is that
the ntp_adjtime() function is limited to a one-second interval due to
overflow in the 32-bit word.
4. In the design of the nanokernel code that leaves here, the time as
seen by the application is not stepped backward unless the kernel clock
is stepped backward more than two seconds. So, if the kernel clock is
stepped backward more than the step threshold and less than two seconds,
the time as observed by an application would effectively stand still or
advance at a low rate for the interval required. There are other
features designed to avoid inconsistent reading of the kernel clock via
various means in and out of the kernel. These features have been
implemented in the stock Tru64 kernel for the Alpha, but so far as I
know have not been implemented in other kernels.
5. If for some reason the server(s) are not reachable at startup and the
applications must start, then I would assume the applications would
fail, since the time is not synchronized. If the applications use the
NTP system primatives, the synchronization condition is readily apparent
in the return code. Since they can't run anyway, there is no harm in
stepping the clock, no matter what the initial offset. Forcing a slew in
this case would seem highly undesirable, unless the application can
tolerate large differences between clocks and, in that case, using ntpd
is probably a poor choice in the first place.
Dave
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
