[ntp:questions] stepping and slewing

David Woolley david at djwhome.demon.co.uk
Sat May 5 14:03:26 UTC 2007


In article <slrnf3ka5n.9rf.kostecke at stasis.kostecke.net>,
Steve Kostecke <kostecke at ntp.isc.org> wrote:

> If your clock is less than 128ms off ntpd slews it. The slew will take
> the same amount of time regardless of how ntpd is running (e.g. as a
> daemon or via a cron-job w/ -gq).

My impression is that -gq will be faster.  ntpdate is certainly faster.
That's because it will slew at the maximum rate all the time, whereas
the filtering in daemon mode ntpd will cause the rate to ramp up slowly
and to ramp down as it gets close to the nominal time.

This, I think is, the cause of one of the concerns that people have about
ntpd startup time.  If the initial offset error, for a warm start, is >~
1 standard deviation, but < 128ms, an optimum approach would be to slew
at maximum rate until one either crosses the estimated zero error, or,
possibly about 1 SD from it, but ntpd doesn't do this and has no carry
over of the SD to allow it to do so.

It probably should not report a valid state until the initial slew 
completes, which may make some people unhappy.  I don't think 
stability considerations arise during the inial slew, so a faster
slew, if supported, should be acceptable.  If it does start reporting
valid times earlier, I think the extended period of high tolerance
estimates will be worse than any instability due to downstream systems
tracking a target that isn't apply the NTP loop filter.

There is also quite a lot of loose terminology being used.  The following
may not be exhaustive, but:

Step doesn't step to the correct time, it steps to the time it estimated 
from a weighted average of recently polled servers.  When you allow the 
system to run in daemon mode, it will get much closer to the correct time,
as the loop filtering will smooth out short term variations in the offset
measurements.

Whilst the actual step is instantaneous, verifying the need for a step takes
a significant amount of time (in the most general case, about 15 minutes).

The 0.5ms/s slew rates are relative to the static error in the machine clock,
so they can reduce to almost 0 in one direction and almost 1ms/s in the other,
in a system with a clock at the margins of usability.

Although the effective slew rate will almost always be less than this, and 
should be so once locked, the user space time discipline will actually
achieve this by a sawtooth with a frequency of 0.25 Hz, in older versions, 
and possibly 1Hz in later versions.  This sawtooth will be at either 
maximum slew or zero slew at any instant.

The typical kernel support for the user space discipline will actually step
every clock tick.  It is theoretically possible for kernel disciplines to
implement an exact slew rate down to the oscillator period.

> Once ntpd has run long enough to determine the correct PLL frequency,
> and write it to the drift file, ntpd restarts are very quick.

Only if the initial measured offset exceeds 128ms.  If it is less than
this, it will run the normal loop filter and take a signifcant amount
of time to converge.




More information about the questions mailing list