[ntp:questions] stepping and slewing
david at djwhome.demon.co.uk
Tue May 8 18:28:22 UTC 2007
In article <4640B782.8070008 at udel.edu>, mills at udel.edu wrote:
> 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.
That's pretty much what I understood.
If one were to summarise, assuming that a step won't happen:
ntpdate converges onto a not very well chosen estimate of the true time
at an excess of +/- 0.5ms/s over the intrinsic clock frequency error. in
the mean time the clock may have drifted as much if the crystal is itself
out by a signicant part of 500ppm;
ntpd -gq converges onto a rather better chosen estimate of the true time at
the same rate, but may take an extra, if trivial, 10 seconds before it starts
doing so. (Actually, I don't know if ntpd -gq will use drift file information
to predict the correction needed at the end of the (including drift correction)
correction period (it ought to, but no one has mentioned it so far - if it
does, that may be a strong indication in its favour for some people));
ntpd in daemon mode converges onto a much better estimate of the time,
achieved by low pass filtering the phase jitter, but, if the initial error
is significantly larger than the unsmoothed jitter, will generally take
longer than the other two methods, to reach the same accuracy, because
it will slew in at a variable rate defined by the phase and frequency
control loops. For a large error and small jitter, with little static
frequency error, that will be of the order of the loop time constant (for
large jitter, it may get to within a standard deviation rather faster).
ntpd in daemon mode will, eventually, cope with static frequency errors
that are not far short of 500ppm.
ntpdate in slew mode, may require a delay of up to 256 seconds before
ntpd is started. ntpd -qg, if it doesn't use the drift file, will require
up to the same interval, if it does use the drift file, the maximum delay
is almost unbounded (an unbounded delay would allow no head room, so,
it might be better to say that it is about 12,800 seconds, i.e. max
clock error is 490ppm.
Actually, thinking about, what nptd -gq ought to do is to use the estimated
total correction at maximum slew rate to test against the step limit, rather
than using the measured offset. I.E., if the error cannot be corrected
in 256 seconds, it should step; with a drift file value of 490, that may
mean 256ms on one direction and just over 2ms in the other direction.
> X-Accept-Language: rs1_83b2e684b6b, rs2_f4ad4998dd6, rs3_d1267aba2e
Curious! Not any ISO languages that I know of.
More information about the questions