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@Home daemon or the Folding@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
