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, 2009 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, 2009 at 16:24
  • It's sold as a dedicated server from theplanet.
    – Nick
    Nov 13, 2009 at 18:57

3 Answers 3


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, 2009 at 17:07
  • Also check your host provider - they may have their own time server. Nov 13, 2009 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? Nov 13, 2009 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, 2009 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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .