Linux clock losing time
 

Hi,

I've got a fairly new PC running SuSE 9.0. Everything runs okay, but I'm a bit worried because the clock seems to be losing time quite badly.

I haven't worked out if it's consistent, but it seems to lose more than a minute in every hour. I've had the machine on all day today, and it's lost more than a quarter of an hour.

It isn't a hardware problem, because it keeps perfect time when it's switched off, so it must be something funny going in Linux, or at least in something I'm running.

Does anyone have any ideas? Is there anything obvious I should be looking at?

Thanks for any advice. :)

Quick rundown of the setup:
Processor: AMD3000
Mobo: Asus A7N8X-E Deluxe
Ram: 1gig
SuSE is the only OS installed on the machine; it was a fresh install with nothing else on the system. I'm using it as a desktop system, running KDE.

I would check 'top' and see how heavily loaded your CPU is. If the percentage is high it might be the problem and 'top' will show you which program might be causing the high system load.

Have a look at /var/log/syslog and see if there are any error messages that might give you some clues.

There are two clocks. The Real Time Clock is an integrated chip on the motherboard that keeps time when the PC is turned off. Once the system is booted the clock is actually a kernel timer which is synched from the RTC. I'm not positive how the OS determines the frequency but it is adjustable. Might want to do some more seraching on the web.

http://gd.tuwien.ac.at/linuxcommand....adjtimex8.html

I had this same issue with my laptop and the battery status icon - oddly having that turned on was effecting the time similar to your issue. Being that you're on a PC and don't have a battery I'm guessing it must be something similar to the battery icon (system monitor, some other app)?

Also, check out: man hwclock

There are a variety of options to set the system clock (displayed on your desktop) to equal the hardware clock (basically the BIOS system time), or vice versa. -- J.W.

Hello,
Check if you have the NTP (Network Time Protocol) daemon running, it is called
"xntpd" on SuSE I think. If so, either turn it off, or (preferably) configure it to
syncronize the clock with some external ntp server.
/L Ekman

Firstly, thanks for all the replies. :)

Now, to answer them.......

It isn't heavy usage. I've been running top as well as ksysguard; nothing special to report there... and in any case, I'm certainly not doing anything more strenuous than I have done on other machines without this problem.

There isn't one. (does this mean I haven't had any system errors since I installed? yay! ;) )

Thanks - interesting link. :) I was aware of this (at the user level), because when I reset the clock after it's lost time, it sometime jumps back to the right time when it loads the setup program, without me having to actually make the change. I guessed it was resetting from the hardware clock, and that made sense since it was keeping time when switched off.

It still doesn't answer the real question, which is why the OS clock seems to have trouble keeping up with the hardware clock.

I would be inclined to believe there is a program causing this, but I have no idea what. It's been happening since day one when I got the PC and installed SuSE (although I only noticed it after a week when I suddenly realised the clock was three hours out), and the only apps I can think I that I've been running consistently all that time would be Konqeror and Kmail (along with the usual suspects in the background processes list - basically the SuSE default plus spamd). And they certainly shouldn't be causing this. Other programs have been used, but I'm still bedding this machine in, so I've been chopping and changing quite a lot - nothing else has been running consistently enough to have been doing this.

I will do. Thank you.

Worth a thought, but I did check that - NTP is definitely switched off.


Thanks again for all the ideas.

I still don't really have an answer to this, though. There were a couple of ideas here on how I might get around it by using the hardware clock, but I would like to get to the root of the problem, and find out *why* it's happening, because I have a feeling it might be causing other problems (I have noticed some speed problems on this system on the odd occasion, even though it's far more powerful than my older machine. And I don't like having that nagging feeling that I might've messed something up somewhere in the setup.

Any more ideas?

itsme, or anybody:
i have this exact problem. my machine runs fine, but whenever i burn a cd and use lame and cdrdao, my cpu load goes through the roof and my clock starts losing time. i estimate i can lose up to about 5 minutes per hour when decoding & burning cds constantly. is there any way that i can remedy this problem without ceasing to burn & encode or buying new hardware?
thanks,
spencer

You might also look into chrony-1.20. It's an atomic clock synchronization utility which references the same NTP sources. But, it's intended for intermittent internet connections, though it will work with a continuous connection. It keeps your clock in sync with an atomic clock. The daemon watches for an internet connection, then goes to work. It also maintains a drift-rate file which it uses to estimate the rate at which your system clock drifts from the atomic clock. The client is a command-line utility used to configure chrony. Better than a wrist watch, eh?

I also had this problem and found J.W.'s response helpful, namely:

man hwclock

Whenever you set the time using hwclock it writes /etc/adjtime. Amongst other things, this file records the time that you last set the clock along with the systematic clock drift rate (i.e. the number of seconds per day by which the hardware clock loses or gains time), calculated using the time you last set the clock. The clock drift rate recorded in adjtime is used to adjust the hardware clock. When I looked at my adjtime file, it had quite a large number for the clock drift rate which caused my screen clock to lose time quite heavily. The hwclock man page just talks about adjustment of the hardware clock, not the screen clock, however I tried setting the clock drift rate (the first number in the adjtime file) so that the clock gained rather than lost ten minutes per day and found that my screen clock stopped losing time and started gaining ten minutes per day. I don't think my screen clock is running off the hardware clock because when I reset my hardware clock (using hwclock) the screen clock did not reset. Nevertheless, the screen clock seems to adjust itself using the clock drift rate in adjtime.

To fix this either set the clock drift rate to zero, delete the adjtime file and reset the screen clock or calculate the correct value for the clock drift rate. I did the last of these by deleting the adjtime file, then setting the hardware clock using:

hwclock --set --date="7/22/01 17:45:05" (or whatever the date/time was at the time)

This wrote a new adjtime file without a clock drift rate in it. A few days later I reset the hardware clock again, which updated the adjtime file with the newly calculated clock drift rate. Since my screen clock does not seem to run off the hardware clock, I had to reset that as well. But my screen clock has worked OK since then.