On 2011-12-13, Harlan Stenn <[email protected]> wrote: ... > Related items: > > - it takes some time to get a good idea of the drift. We have seen that > we can get the drift calculated to 3ppm or better in 300 seconds, so > we should be able to get the drift calculated to 30ppm or better in 30 > seconds' time. Miroslav says that from lan-based sources chrony can > get <3ppm with about 10 seconds' worth of samples, but it takes 10s of > minutes to do the same thing on a wireless network. > > - as far as ntpd is concerned, if the underlying clock has an intrinsic > drift of less than 500ppm (as measured against "nominal" time) it should > be able to keep the clock sync'd (monotonic time, no steps). > > - If the reference time(s) that ntpd follows do not jump around by more > than ~128ms, ntpd will not 'step'.
The problem with ntpd is that, if the drift file is out (eg because of the recalbration bug in Linux) by say 100PPM, then ntpd can well exceed that 128ms threshold because of the way that ntpd works. -- it sets the time initially (becuase of the 128ms threshold) but then begins to drift. It takes a while for ntpd to realise that the drift is taking place and it slowly alters the clock rate to compensate. But in the meantime, 128ms of offset has been accumulated, and the clock jumps. At which point it has to work hard again to compensate for both the rate problem and the discontinuity. This is not a problem if the drift file is an accurate measure of the system rate. Then ntpd can rapidly get to the right time and drift rate. This is one of chrony's great advantages. It does a separate absolute measurement of both the offset and the drift, and rapidly converges to the correct clock rate and time. It does this by remebering past offset measurements (compensated for the rate changes and offset slews performed by chrony) so it can have a long baseline to measure the drift against, and many measurements so it can accurately estimate both while minimizing the effect of statistical fluctuations. > > ntpd considers itself "syncd" when it has what it considers to be a > good idea of the drift and knowledge of the correction needed. Once > this is known, ntpd will step or slew the correction and shift from > leap==11 to leap!=11. (This sentence is pretty lame - with more > research I could do better.) > > "ntpd considers itself syncd" does not mean that: > > - its idea of the drift is accurate/precise to better than a few ppm > - the offset to reference time is any better than 128ms > - the jitter or dispersion values are particularly "good" > > Under some circumstances it may take may hours to achieve this level of > stability. But in the interim, assuming the above constraints have been > met, the clock is sync'd and has stayed that way. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
