Results 1 to 3 of 3
I have some CentOS 5.2 systems where the clock is skewed by a few seconds. We have a number of servers, lets call them app1..app10. Each of these is running ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 10-08-2009 #1
- Join Date
- Oct 2009
NTP Clock skew
I have some CentOS 5.2 systems where the clock is skewed by a few seconds.
We have a number of servers, lets call them app1..app10. Each of these is running ntp and syncing off a master, called ext3, which is in turn syncing from public ntp servers, probably the default ones.
Some of these app systems have their clock slightly skewed by a few seconds (I've been told, but can't confirm it has gone as high as 60s sometimes). The ntp.conf file is the same on all of them.
The hardware and version of CentOS on all these app systems is identical. Ntp version is 4.2.2. Anyone got any ideas?
I also noticed that the hardware clock (as shown by hwclock) seems to be a few seconds off on these skewed systems (but closer on the non skewed systens). Seems like too much of a coincidence to be unrelated, but ntp doesn't use the hardware clock as part of it's algorithm does it?
- 10-09-2009 #2
- 10-15-2009 #3
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
As they say, this should not be happening... provided that you are actually running ntp on each of the systems in question and there have been no communication issues between the skewed systems and the local ntp server. You might want to check both that the ntp client software is running on each system, that the crontab entries are correct, and that something else isn't interfering with the clocks, such as a process that changes the time to the hardware clock. FWIW, I have my system configured to resync the hardware clock with the system clock that is set with NTP whenever I reboot the system. Remember, that by default NTP will only gradually update the system clock if it was too far off to begin with, so if your hardware clocks are bogus, then you might have an explanation for the skew.Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!