[ntp:questions] A ntp client is running ahead of time of our netowork ntp server.

David Woolley david at djwhome.demon.co.uk
Thu Feb 1 21:55:46 UTC 2007


In article <45C1F3F5.2090001 at rokcorp.com>,
chuck.amadi at rokcorp.com (Chuck Amadi) wrote:

> *LOCAL(0)        LOCAL(0)        10 l   52   64  377    0.000    0.000   
> 0.001

Firstly get rid of this.  It might just be sufficient to break it on its
own, although I tend to think that your jitter figures are too large to
be explained just by a local clock that is off by 500ppm (assuming that
you are using real references clocks on the servers).  However, it is 
always going to confuse issues.

Only add it back when all the following are true:

- the system is working well as a pure client;
- you are using it as a server for other machines;
- you expect outages of several hours and you want the sub-clients to
  track you very closely during the outage, even though, on average, they
  may have worse absolute times.

>  client.ntp.rok xxx.43.128.xx    3 u  381 1024  377    8.937  -64924. 
> 1018660

This jitter is huge.  Your clock frequency error is probably very high and
either the correction has hit the end stop, or the local clock has confused
ntpd into thinking it is better even without a correction.  It might just
be worthwhile doing rv 0 to find the frequency correction being applied.
(Alternatively, you are using W32Time upstream without a proper reference
and the root dispersion is very high.)

>  server.rokcorp xxx.43.128.xx    3 u  460 1024  377  979.258  -60744. 
> 1020191

The delay is unusably high.  I don't think this can just be from an extreme
frequency error.

> I have for tmp measures created a cron job as below::

0 2,6,10,14,18,20,22 * * * /usr/sbin/ntpdate -s -b -p 8 -u xx.0.2.x

would have been simpler.  I hope you have disabled ntpd, as ntpdate
and ntp don't coexist well.

How much does the time step every time this job runs? From that work
out the frequency error in parts per million.  Is it more than about 
450?  If so, you need to get the OS to keep better time uncorrected, before
you start trying to synchronise it.  Modern machines should be within 
about 20 ppm.

You are running 70 seconds fast, so lost interrupts aren't a prime 
cause in this case.  Other options are:

- conflicting time synchronisation software;
- motherboard crystal broken;
- power management is making the TSC calibration unreliable;
- your root server is running W32Time with only its own clock as
  reference (use assoc and rv to find out the root dispersion).

> # As real clocks drift, need periodic corrections

The clock that is used by ntpd is not the RTC, it's the clock that decrements
a CTC used for software timing.

Note that you are in FAQ territory, so reading the archives would be a good
idea.

> This email is confidential to the addressee only. If you do not believe

Strange concept of confidential.  Do you always mean every sentient 
being within the light cone of the posting is allowed to read your
confidential documents?




More information about the questions mailing list