[ntp:questions] Re: tinker step 0 (always slew) and kernel time discipline
David L. Mills
mills at udel.edu
Fri Sep 22 17:33:11 UTC 2006
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.
David Woolley wrote:
> In article <eeucua$5q9$1 at zcars129.ca.nortel.com>,
> Joe Harvell <harvell at nortel.com> 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.
More information about the questions