[ntp:questions] ntpdate removal is coming

unruh unruh at invalid.ca
Tue Dec 13 17:41:45 UTC 2011


On 2011-12-13, Harlan Stenn <stenn at ntp.org> 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.



More information about the questions mailing list