I have two Ubuntu servers which synchronize their timestamp to europe.pool.ntp.org every night. Just before they sync, I can see a difference of 4 seconds between the two servers. One of the servers seems to deviate from 4 seconds in 24 hours.

  • Is it rather an hardware problem or software problem ?
  • Is there a way to correct this, aside from syncing several times a day ?
  • If the only solution is to sync more often, is there any fallout for the server ?

Thanks, Olivier

  • It's most likely a hardware issue, and aside from syncing more often (which won't be an issue for the server), I don't think there's much you can do. – user3914 Feb 25 '11 at 0:21

Clock drift is absolutely a normal part of time keeping on a computer, but the details on how much drift occurs can be a function of a lot of different things. In the event of "abnormally large" skew the reasons can range a low quality hardware clock to a system with high utilization. So keeping yourself synchronized with an external, canonical, time server is a very important step.

The best setup is to use ntpdate to hard set the time on boot, and then use ntpd on going to account for clock skew. I have heard complaints in the past about ntpd being resource hungry (I cannot speak to the accuracy, only that I've heard the complaint often), but modern implementations are nearly unnoticeable. The true elegance of ntpd lies in two main points:

  • It will monitor clock skew over time to determine how quickly your clock drifts and adjust it's polling frequency accordingly
  • Whenever a sync occurs, it will use those drift calculations and slowly bring your clock back into time

This has the great advantage of minimizing the impact of time changes on your system, e.g. you won't have situations like timestamps in logs appear to jump around.

I would highly recommend setting multiple servers in your config, this can easily be done by editing the file /etc/ntp.conf and adding multiple server statements. For example;

server ntp.ubuntu.com
server 0.pool.ntp.org
server 1.pool.ntp.org

For some discussion on what public NTP servers are available you can see the question -- Public NTP Servers

One caveat with ntpd is this: if your time is too far off, then it will not correct your time. To quote the man page (according to RHEL5.6)

In case there is no TOY chip or for some reason its time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock byhand. This causes ntpd to exit with a panic message to the system log.

This is why I consider hard setting the clock at startup time important. While the machine is off you are relying on the hardware clock and the CMOS battery to keep the time. Also, in the case of a VM, reverting to snapshot will almost definitely trigger this condition. Keeping this in mind is an important consideration if you are using time sensitive applications, such as kerberos authentication.


It's a characteristic of computer clocks. You can read a little about it here and a little about clock drift on wikipedia.

Sync more often is the best way to attack that. I normally sync clocks every hour with a local server that syncs externaly once a hour too. You can have more than one server to provide fallout to ntp.

There are some ntp pools you can use that are synced with high resolution clocks like ntp.org.

  • 1
    +1 for syncing to a local server - this way, you will at least be internally consistent. – Andrew Feb 25 '11 at 2:07

Just use ntpd. It diminishes the loads on the servers by talking to them when they are less busy and have less latency. By running continuously it can monitor the clock more closely and model drift with more parameters than just speed.

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.