The system clock on my dedicated server is running too slow. Every month it loses about 2 minutes.

The details are: Cent OS, Linux version 2.6.9.

How can I resolve the problem, is there any way to check whether it's a hardware or software?

  • 2
    Just out of interest one reason clocks can run slow is if the server is a virtual one, it might be worth you checking just how dedicated your server really is. – Chopper3 Nov 13 '09 at 15:27
  • What Chopper3 said; if it turns out that you're on a virtual machine, VMware has a few recommendations for running Linux guests under their product: kb.vmware.com/kb/1006427 (Note that, for RHEL4/CentOS4, the recommended kernel options are "clock=pmtmr divider=10".) However, you should definitely be running ntpd, if you aren't already. – esm Nov 13 '09 at 16:24
  • It's sold as a dedicated server from theplanet. – Nick Nov 13 '09 at 18:57

You can resolve the problem by running NTP. If it isn't already installed you should be able to do something like

  yum install ntp
  chkconfig --levels 235 ntpd on
  service ntpd start

You may have to give it a while to sync the first time.

  • Take a look at the NTP pool as well for time sources. If you want your clock to be as close as possible, choosing some geographically close time servers is very helpful. pool.ntp.org/en/use.html Also, if you have some spare cycles (very few), and some spare bandwidth (not much), joining the pool is always a nice thing to do :) – J.T.Sage Nov 13 '09 at 17:07
  • Also check your host provider - they may have their own time server. – Douglas Leeder Nov 13 '09 at 17:59

2 minutes a month isn't too bad. NTP should be able to happily correct that amount of drift.

If it hasn't always been this way and you're able to take the machine down, then try replacing the CMOS battery. They're cheap and you might find that it resolves the issue.

Anecdotal story for you:

I have in the past seen a running machine which was exhibiting 500~ PPM drift. Equating to about 45 seconds a day. It was far too much for NTP to correct on-the-fly. I tried all kind of things to fix it including a new kernel and different RTC classes.

At my wits' end, and against the logic that it should affect a running machine, I replaced the CMOS battery with a fresh one. A multi-meter showed only a very small difference between the old and new batteries. It fixed the clock drift.

  • Why couldn't NTP fix this? Passing some explicit or an intrinsic limit? – Thorbjørn Ravn Andersen Nov 13 '09 at 20:45
  • NTP daemons typically fix clock drift by making adjtime(3) system calls, which causes the system clock to slow down or speed up in small increments, in order to reach a desired point. It does this in small increments because some applications become rightly upset if the clock warps a large amount in a small space of time. There is usually an upper limit on the -/+ delta that NTP daemons and adjtime() will entertain, because at such high drift rates the clock will simply never reach the desired point by making those small adjustments. – Dan Carley Nov 14 '09 at 12:45

The easiest way to get round the problem is to have your server sync regularly with an NTP time source, this way it should get corrected quickly if it starts to drift.

If you are not using NTP then your computer will be relying on the internal clock. If this is losing time it's often a hardware issue, either with the clock itself, BIOS, or the CMOS battery (although this should be less of an issue if it is not restarted often).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.