In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
