[ntp:questions] A ntp client is running ahead of time of our netowork ntp server.
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
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.
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.
The delay is unusably high. I don't think this can just be from an extreme
> 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
> 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
More information about the questions