Clock will not properly keep time, Suse 10.3

Seems like a problem which should be simple to fix, but I'm stumped. This machine is an eMachine T5246 desktop, about a month old. Suse is dual-booted with Ubuntu 7.10, and aside from this particular problem, everything else in each system works well.

I've reset the clock probably five or six times, but every time I think to check it, the time is off again, sometimes by several hours. The clock in the Ubuntu system is perfect so I think I'm just missing something which should be obvious in Suse - or I'm just plain dumb as a rock. Any suggestions welcome - for the clock, or a cure for my being a dummy. LOL

 

For a linux only computer, check that linux inteprets the Real Time Clock as UTC time (and not as localtime) in each of your linux OS. Then ensure the timezone is set the same in both the linux OS.

Only if you are sure of the settings above should you consider enabling ntp, which can be used to correct a drifting RTC, but that is meant for hardware clocks that drift by seconds or minutes per day not hours!

 

Thanks for the response, timberwolf. Going to have to do some reading, though, in order to decipher your post. LOL

Thankfully, with your comment and the help of Google, I'll probably be able to fix this little issue - or I'll actually have to wear my watch occasionally.

 

I had to opt for a generic explanation, partly because each linux distro has a different interface to set these values, and partly because some folk on this forum really don't like typing commands into Terminal windows.

It might be better to search for Hardware clock instead of Real Time Clock (I still remember computers being advertised with battery backed RTC as a selling point).

I've had a play with an openSuSE 10.3 Live CD, and that has a default of localtime for the Hardware Clock. Assuming that the default for a hard drive installation is the same as the Live CD, I would run up the Control Center/YaST2 and look at the Date and Time settings.

 

see if you have ntpd running in ubuntu. if not, clock drift is probably acting differently between the two distros. if you want it consistent, just implement ntpd.

 

FYI I'm running OpenSuse 10.3 on my new T61p and the clock has been stable with and without ntpd running.

 

Thanks guys. Have got it running properly now.

 

Good news. BTW it could help others if you say what fixed your problem.

 

I wish I had something more intelligent to say than I reset one last time, and then booted from Suse into Ubuntu yesterday afternoon. When I went back to Suse today, the clock was, and continues, to be on time.

I know, lousy answer, but I really don't know what exactly did the trick. I was in the process of looking up all the abbreviations, etc, from above, when I decided to just give it one more shot the easy way. Presto!

 

You shouldn't be so hard on yourself, that response was useful.

szandor said it was probably due to clock drift between the two distros. What I think he meant was that Ubuntu and SuSE were compensating by different amounts for the Hardware Clock drift. That'll be about as clear as mud? So I did some research and this is what I came up with:

A PC contains two clocks, a Hardware Clock and a System Clock.

A Hardware Clock keeps time when the PC is not running (switched off), but they are not very accurate timekeepers. So one PC may have a Hardware Clock that loses 2 minutes a day, and another PC could have a clock that gains 30 seconds a day. Although the Hardware Clocks aren't accurate, they are at least consistent about how much time they either gain or lose.

A System Clock, is actually a software clock, it is the system time that the linux kernel maintains and uses. The System Clock is more accurate at timekeeping than the Hardware Clock, so the System Clock can be used to measure the drift of the Hardware Clock and then can used to compensate for the drift.

The following is a contrived example, of how I think it works in a linux dual-boot situation. I've made some assumptions, that the Hardware Clock loses two minutes a day (24 hours) and that each linux distro has measured the same value for the Hardware Clock drift.

Let us start with a blank hard drive, on which we install Ubuntu. As part of the installation, we set the time, and then we run the distro for 12 hours and then we shutdown the PC. When we set the time, what the system did was set the Hardware Clock and the System Clock. After 12 hours, during the linux shutdown, the System Clock is compared with the Hardware Clock, a file is written to the hard drive that notes that the Hardware Clock lost 1 minute (in 12 hours), after noting the difference, linux writes the System Clock time to the Hardware Clock.

Next Day, 12 hours later, we start our PC, linux reads the Hardware Clock, reads the file with the note about the Hardware Clock drift, and performs a calculation to adjust the System Clock to give the real time (as we see on our amazingly accurate atomic powered wrist watch!).

After using Ubuntu for a while, we get tempted to try another linux distro. So we shutdown Ubuntu, it does the usual Hardware Clock and System Clock measurement and saving.

We install SuSE, and it performs the same checks on the Hardware Clock and creates a note of the time drift into a file that SuSE keeps. We like SuSE so much that for the next 10 days, on a daily basis, we only boot SuSE. The time in linux compared with our amazing wrist watch shows the same time.

After the 10 days, we decide to boot Ubuntu, during the startup, the Hardware Clock is read, the Ubuntu file recording the time drift is read, as far as Ubuntu is concerned the PC has been off for 10 days, so the Hardware Clock must have drifted 2 minutes per day, so System Clock is adjusted by 20 minutes!

The man pages for hwclock and adjtimex contain technical descriptions about the clocks. There was also a page on dual-booting that I came across, but I forgot to save the URL.

 

Damn, you put a lot of effort into that, timberwolf. Your explanation seems logical and makes sense to me. I'd never have been able to put into words (even if I had found this info and truly understood the entire process), a detailed coherent walk-through or summary such as yours. Thank you.