[ntp:questions] stepping and slewing
mills at udel.edu
mills at udel.edu
Tue May 8 17:46:42 UTC 2007
There may be some misunderstanding when comparing ntpd -gq and ntpdate.
The ntpdate volleys a few packets with one or more servers, develops a
consensus and calls the adjtime() kernel routine. The ntpd -gq does the
same thing, but uses its fancy mitigation algorithms. When a consensus
has been reached, defined as the time the ntpd daemon would first set
the clock, it calls adjtime() just like ntpdate. Using iburst this
normally happens in less than ten seconds.
The ntpd -gq behavior can be modified using the tinker and tos commands.
If the step threshold is exceeded, the clock will be set directly using
the settimeofday() kernel routine.
David Woolley wrote:
> 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
> 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