[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


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 <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 mailing list