Server clock running too slow

Question

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?

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: http://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

score 13 · Accepted Answer · answered Nov 13 '09 at 15:22

13

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.

answered Nov 13 '09 at 15:22

carson

1,630
11
15

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. http://www.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

score 4 · Answer 2 · answered Nov 13 '09 at 16:59

4

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.

answered Nov 13 '09 at 16:59

Dan Carley

25,617
5
53
70

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

score 3 · Answer 3 · edited Dec 03 '09 at 17:52

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).

Server clock running too slow

3 Answers3

Linked