Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm researching a bit of a problem maintaining time synchronization between systems. I finally decided to measure the actual clock variance between hosts, and found that over the course of 13 hours, there was a rather large (IMO) drift. Relative to the 'main' host:

  • systemA gained 3 seconds
  • systemB gained 2 seconds
  • systemC lost 7 seconds

Is this a relatively normal scenario? The 'main' system and systemA are brand new HP DL380's, while systems B and C are 2-3 years old.

We're going to check the CMOS batteries, but I don't know if that affects how the clock runs while the system is powered on.


share|improve this question
Which OSes are you running? Are you running ntpd on all systems? – Cakemox Apr 20 '11 at 12:08

You've not mentioned what OS this is running - since you're using ntpd, I'll assume its Linux/Unix/BSD.

The clock where the OS gets its timestamps from is not the hardware clock - these are 2 seperate entities (IIRC its not part of POSIX, but most Unix type systems provide a utility hxclock to interact with the hardware clock). The system clock is set from the hardware clock at boot time (and the hardware clock should be set from the system time at shutdown - but implementations vary).

You've tagged this as ntpd - but are you currently running ntpd (configured to use a valid server and read/write access to the drift file)? If not, then even a couple of seconds per hour is not a huge amount to be concerned about - just setup ntpd and it will learn how the system clock drifts relative to the server time and work out how to compensate via adjtime[x]. If you are already running a correctly configured and trained ntpd, then there's something very screwy going on here.

share|improve this answer

Yes, it is. Sucks majorly, but it is. It is not that high a skew - 13 hours have 46800 seconds. This is some minor tolerances in the frequence qaurts for the cpu ;)

I know some high precision systems (one rtp mass distribution, one financial maket data) and BOTH have their own time sny mechanism (rtp: based on a custom ntp client, market data anyway wsends a lot of udp packets that also contain a time signal).

The computer closk is "good enough" for most uses and that is what it is for. Fopr anything more specific use special hardware. My market stream calculates my system clock skew at 39ms / hour ;)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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