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