system clock is too slow

[Erik Hemdal]

On Tuesday 27 July 2004 7:20 pm, Rick Stevens wrote:
> ntpdate drags your machine kicking and screaming into compliance with
> your NTP servers RIGHT NOW, while ntpd KEEPS it current. If ntpd has
to
> pull the machine into compliance, it does it just a little bit at a
time
> so it may take quite a while for it to get it synchronized. Once the
> clock is synched, ntpd will keep it synched.

>Wow! Thanks for that wonderful explanation Rick. Now I understand >it. 
I'll 
>definetely run ntpdate at boot and will run ntpd as a daemon!

>Thanks Rick and Ben!

The larger question, beyond use of ntpd, is why the clock runs slow. 
I've only seen this happen on systems that are extremely heavily
loaded.  When the system runs near 100% load all the time, the real-time
clock interrupt gets starved, and the clock drifts back.  And the only
time I've seen this occur is with a computer running a heavy compute
load, like the SETI at Home daemon or the Folding at Home program.  I'd
investigate this if you are running programs like this and your computer
sits otherwise idle for a long time.

Be advised that ntpd can cause you some grief when it has to do a lot of
"slewing" as Rick described.  I had to build and install some Perl
packages from CPAN recently, and the "slewing" altered timestamps enough
to confuse the tests and cause the installation to fail.  

Using ntpd is a good idea, but take some time to try to find the root
cause.

Hope this helps...Erik