On Tue, Jul 27, 2004 at 11:17:35PM -0400, Erik Hemdal wrote: > > 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. > I've experienced this on one of my systems. I've been running the distributed.net client, which pushes CPU load to 100%, and the processor is also significantly overclocked (around 10%). Under Windows I'd have the system lose 15 minutes or more a day. After reboot the clock would be right again. I don't have this problem under Fedora, but I assume ntpd is the cause of that. I'm pretty sure the problem went away when I backed off the overclock. I don't run Windows enough any more to test this. I know when I stopped using Windows the system was keeping good time and I was still running distributed.net with no overclock. I had another system that ran stock speeds on a new motherboard, ran distributed.net, and lost time. I think both factors are worth checking out.
