In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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? _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
