[ntp:questions] Re: Linux NTP Polling

David Woolley david at djwhome.demon.co.uk
Sun May 22 18:10:43 UTC 2005


In article <fn_je.724$oj7.17795 at nnrp1.ozemail.com.au>,
Geoff <g_wynn at ozemail.com.au> wrote:

> NTP server but does not maintain correct time.  It displays the difference
> in time, when the NTP server is omved forwards or backwards as in the Daemon
> displays 76s or -45s etc but it does not change the actuall time to reflect.

76 or 45 seconds are large steps.  Time itself doesn't step, but the 
measurement can step by the variability in the differential propagation
time of the protocol messages.  That will be typically under 50ms and
never more than 2 (1?) seconds (as this would involve a step from 
maximum root distance in one direction to the same in the other direction).

Your large steps won't resolve until enough samples (possibly at a 1024
second poll interval) have been accumulated for the filters to output
the revised time and until after a further sanity check period of about
quarter of an hour has expired, and then until after the five or six 
minutes for the filters to prime themselves with times consistent with
the new idea of reality.

It's also possible that you have disabled stepping, in which case
the the correction rate will be limited to +/- 500ppm relative to the
actual local clock free running frequency.  If that frequency is poor,
the absolute rate may be close to zero in one direction and close to
1,000 ppm in the other.

The error recovery mechanisms will eventually cope with changing to or
from a good clock or between bad clocks (the latter case applies for
free running LCL clock sources), but this is error recovery, not a
normal function.

The correct way of verify lock is to look at the stratum and reference
ID for the machine or to use ntpq to check that a peer has been selected,
and that the frequency correction has stabilised.



More information about the questions mailing list