Am Donnerstag, 23. März 2006 15:32 schrieb Jerry Feldman:

On Thursday 23 March 2006 8:37 am, Per Jessen wrote:

...

Daniel Bauer wrote:

...

I then adjusted date and time with click right on the watch in the kde task bar, ("set date and time") to March 20, 2006. Today it shows May 27, 2008...

Did you also set the hardware clock? "hwclock --systohw" - or in the BIOS.

...

b.t.w.: where the PC stands it's not possible to connect to the internet, so I can't use ntpdate or something like that and have to do it manually somehow... but how?

If the builtin clock is actually unreliable, you'll some other source of time. It doesn't need to be on the internet, any internal network would be ok too. If it cannot in any way be connected to a network (with a reliable time source), perhaps you could attach a DCF77 receiver or something like that.

I would agree with per. But, I suggest you run a test, by booting your system into the BIOS and setting the hardware clock manually. If you an let the PC run for a period of time where you suspect that the time is being trashed, check the BIOS time again - make sure you don't run an OS.

If your hardware clock is the one that is bad, then you have identified the problem.

Then boot up in Linux and make sure that the time zone is set correctly. If you do not dual boot Windows, then it is best to set the hardware clock to UTC time, otherwise set it to local time. Once you have made sure everything with Linux is set correctly, bring up a terminal window or a virtual terminal (control-alt-f1). Actually, I would initially boot into run level 1 or 2, and use the date command to check the time. Linux does set the hardware clock on shutdown, but not when it is running. So, if you see a significant drift, physically power off the system, and check the BIOS. Again, you want to find out where the drift is coming from.

The last test is from KDE. Just repeat the tests you did with KDE. But, you should already have identified that the culprit is either the hardware or Linux.

-- Jerry Feldman Linux Expertise Center (PTAC-MA/TX) Hewlett-Packard Co. 200 Forest Street MRO1-3/K12 Marlborough, MA 01752-3081

508-467-4315 (http://www.testdrive.hp.com)

Thank you Per & Jerry, I'll check that tomorrow when visiting the customers office and then give feedback here... Daniel

J. Scott Thayer wrote:

On Thursday 23 March 2006 06:52, Daniel Bauer wrote:

<snip>

This seems to be a common problem with some installations including my Acer laptop with 9.3. You can find references to it in the archives and no one has ever presented an adequate explanation or solution. Now you knew saying that no one had presented an adequate solution would fire someone up :)

I too have been presented with this anomoly only on SuSE 9.0 and have, after many frusrated hours, been unable to get my clock to behave itself and not report the incorrect time. My clock seemed to advance notibly after a few shutdowns. I monitored the shutdown log ie the one that displays as the machine is shutting down, and noticed that the hardware clock was reset to the current system time. When the system was restarted it would get the CMOS time and increment it by, I assume, the /etc/adjtime file. This ended up putting my clock ahead of time which was compounded when I next shut the machine down. I did not rectify the problem and ended up routinely deleting /etc/adjtime and then resetting the time via Yast. On SuSE 9.2 I have not had this problem and I can therefore only assume that it does not write the SuSE time back to the CMOS clock. Of course if you should have a permanent internet connection, then I would setup for your machine to use NTP. HIH but I would still like to know if what I think was causing it, is causing your time drift.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-03-26 at 17:17 -0500, J. Scott Thayer wrote:

I usually get beat up whenever I post here but it is probably my fault usually, in ANY case... There was another response to your message that purported to solve this problem. I set my clock via KDE to my trusty atomic clock on the wall. I then set the hardware clock and deleted /etc/adjtime. So what? It is now 1537 but the taskbar says it is 1708. No I didn't reboot, if someone actually thinks that would matter, let me know. The point remains, the software clock runs too fast in SOME hardware/software configurations and no one has figured out why. If I have missed the simple solution somewhere I apologize and please point me in the right direction.

There are two different issues here, namely: 1) * Symptom: right after a reboot the clock is off by large ammounts, and stays with the same difference if you do nothing about it. * Solution: setup the clock by your prefered method hwclock --systohc rm /etc/adjtime (in that order) 2) * Symptom: after seting up the clock, it drifts while the computer is running. * Solution: probable kernel problem. Note: when in doubt about the clock, use the command "date" on a console or xterm. Do not trust applets, like the kde clock. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEJxkxtTMYHG2NR9URApLCAJ4tm50ccfbJEStOAll/B0YkXREbvwCggVep AnSDpN113QPwf6b7AVBpiIY= =ma7R -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-03-26 at 22:05 -0500, J. Scott Thayer wrote:

My problem is number 2.

Ough :-(

I also just went to a console via Cntrl-Alt F2, ran date and got the same result as showing in the KDE applet. This way I was fully out of KDE and X yet no change in the issue. I believe it IS a kernel problem but the kernel gurus have not identified it (they HAVE looked).

Bad luck :-/ I can tell you some "hacks" that might work. If you have a permanent network connection, you can set up ntp client, and that will discipline the system clock - provided the clock drift is fairly constant and within limits (and I don't know how tolerant are those limits). Otherwise, you can setup a cron job that set up the clock periodically before it drifts too much. Again, if you have a permanent network connection, I'd call "rcxntpd ntptimeset" periodically, with an interval calculated to make the drift not bigger than a second or two (however, cronjobs can not be called oftener than one per minute). The command "rcxntpd ntptimeset" will call /usr/sbin/ntpdate. If the error is less than 0.5 seconds, it will adjust the clock slowly (slew). If the error is bigger, it will "step" the clock, ie, set it up on time abruptly (wich might be bad for some programs, like the X server, for instance). Finally, if you don't have a permanent network connection, you can set up the cron job to call instead "hwclock --hctosys --noadjfile". Try out the command first on an xterm; if the time is incorrect, and your CMOS clock (the bios) keeps UTC (aka GMT) time, add "--utc" to the command above. Otherwise, if it keeps localtime, add "--localtime". I added --noadjfile to make it ignore the /etc/adjfile file, because it will contain wrong data. However, if you think you can correct it by hand, do it, of course, and remove that option. I can not tell you how to calculate the correct value, however: but you might look up the source code and learn it - and then tell me, I'd like to know ;-) HTH. Further reading: man hwclock file:///usr/share/doc/packages/xntp-doc/html/ntpdate.html http://susefaq.sourceforge.net/howto/time.html - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEKDo1tTMYHG2NR9URAuITAJ9BC0WPe0DbUSK/eHIFy2T+i50yQACfSI4X qPhcCY6KRIT8KShftNt5kPA= =niTN -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-03-27 at 12:08 +0200, Daniel Bauer wrote:

I did what you suggested under 1), Carlos, and it seems that the clock is now running quite normal (well, I had only two hours time to check, but as the clock advanced to April 2010 over the weekend, I guess I would have noted if it would still run that fast...)

Er... (1) only has effect during bootup, ie, for the operation of setting up the the clock on time when the computer is powered up. To clarify things, PCs have had, nearly always, two clocks: the "CMOS" clock (it runs on bateries), and the system clock. When I say not to trust the kde type applet, it's just because some times it doesn't read the clock correctly; so to make sure, I recomend using date on an xterm. Full explanation: http://susefaq.sourceforge.net/howto/time.html - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEKDLitTMYHG2NR9URAkRJAJ9ONH5qf6DrWpOXx8pKhMrNXA+6UQCglYJd HyxT43hI/fHMgdJdCpB4pfM= =o+B4 -----END PGP SIGNATURE-----