Slashdot Mirror
Weird PC Clock Behavior?
cybercyst asks: "I've been having a problem with this for quite some time, and thought it was just me -- until two good friends of mine experienced the same problem. What we are experiencing is best described as a time-skew: our system time is apparently jumping forward an hour, and then returning to normal. It repeats this multiple times, and as far as I can tell only a reboot is any sort of remedy for this, albeit a temporary one. As you can imagine this causes all sorts of problems (under windows managers xscreensaver is always popping up -- in fact as I wrote this, the screensaver has come on over 10 times, negative fps in OpenGL programs, extremely large ping times, and so forth)."
"Friend A runs an Athlon system on a Soyo Dragon motherboard, I'm running a K6-2 450Mhz CPU on an older Epox motherboard. We are both running Slackware 8.0 with kernel 2.4.17, but Friend B runs nothing but Red Hat, and kernel 2.4.2-2.
I have personally tried many things to get this fixed permanently, including setting the time with 'date -s; hwclock --hctosys; hwclock --systohc' the BIOS is set to the right time that doesn't seems to help! So, I'm asking Slashdot, Has anyone out there encountered a similar problem, and if they have, have you been able to fix it?"
Have you checked for nearby chronoton emisions?
Try a tatacion burst, that normaly helps...
"Oh no, not again"
Nothing beats your very own nuclear clock on a PCI card. The best they can make you is a rubidium standard clock accurate to 10^-13 seconds. Cesium beam clocks accurate to 10^-17 seconds are available in rackmount form. Great for all those Mission Critical Real Time applications like Quake III.
If voting were effective, it would be illegal by now.
You might have to delete /etc/adjtime after adjusting your clock. This file is updated now and then to prevent clock drift.
'man 8 hwclock' and 'The Adjust Function' might give you some answers.
Give it a shot, at least.
Jakob Breivik Grimstveit
"I love deadlines. I love the whooshing noise they make as they go by."
It's not a virus? I received an e-mail that advised about a terrible virus that no antivirus company could defeat, and both IBM and Microsoft were very concerned with it, althought, of course, they also could nothing to stop this beast.
Have you by chance opened an e-mail with subject "Good Times"? You should have deleted it upon receipt. Now you're infected. And, because of the name "Good Times", it sure can change your computer time.
That was an easy one. Next !
[from http://www.debian.org/doc/manuals/system-administr ator/ch-sysadmin-time.html]:
Computers have a clock to keep time. Usually there is a hardware clock with battery backup to keep time when the computer is off. The operating system (for example Linux) runs its own clock, and from this clock comes the time shown by commands such as date in Linux and time in DOS.
The hardware clock is usually accurate enough, provided that the battery has not run out. If the time shown by the computer when you turn it on is wrong by several months or years, it is worth checking if the battery is still usable.
The "software" clock in the operating system usually has drift, either systematic or random. This drift means the clock runs too fast or too slow. For this reason it is necessary to use some accurate time source to syncronize the operating system clock if accurate time is needed.
[my opinion:] Normally I'd just say: Use NTP. But your random time drift seems to be so high, NTP would freak out.
It seems to be a hardware problem, or some friend made a practical joke on you, inserting some random time drift in crontab. Try to reinstall your OS and check if this behavior continues. If so, you should change your motherboard. And try to get a good one, like Asus.
I know where you are coming from! This time shift has been a major headache for me at work. My group installs computer systems at emergency management agencies (EMAs) that selectively trigger radios by a precoded geographical zone or serial number. We have a security feature in our broadcast that is basically a time stamp - the radio rejects a broadcast if the timestamp is more than 5 minutes off its internal clock. This prevents somebody from taping a monthly test message and rebroadcasting it at three in the morning to falsely trigger the radios. Well, at the EMAs they just want to sit down at the PC during an emergency and click on a button - so the PC is ignored until it's really needed and then they don't want to waste time checking to see if the clock has jumped. If it has, oops, the broadcast timestamp doesn't match and the radios don't trigger!!!
We have never figured out how to stop the computer time from jumping and if anyone else has, please let me know! The workaround solution we've come up with is to either install a network time update program running in the background if the computer is on the web (for examples, search for "time sync" hereor for the more common rural EMAs that have no Internet connection, we install clock boards. We have found three sources for clock boards: Beagle Software, OutSource and ICS Advent. The Beagle product is ISA only, the OutSource product only works with Win 2000/NT (not Win 95/98) and the ICS product is far and away the most expensive. If anybody knows of others besides these three, please let me know!
once a linux system (i'm presuming you're using linux because you mentioned hwclock) has booted it doesn't use the hardware clock to keep time any longer and instead relies on the kernels own internal timing structures. in short use ntpd, it will query a time server periodically and correct your clock drift.
for more info on how linux keeps time checkout the hwclock and adjtimex man pages.
You want to be sure that you only have one time synchronization daemon running. It sounds like you might have more than one, with one misconfigured to ignore daylight savings time or something similar.
ntp is the most robust free time synchronization software. Try using that in preference to rdate, timed, timeslave, etc. Test ntpd by using "ntpdate" against your upstream ntpd time servers to make sure they do what you expect.
Every time I've mentioned this, I've been told that I'm either trolling, or my clock needs a new battery. But if's FUCKING ANNOYING when your backup script, which includes shutting down the database, is croned to run at 4 AM, runs at pretty much random times.
Vintage computer games and RPG books available. Email me if you're interested.
My machines have done very similar things in the past. You need a new BIOS battery, that's all. Radio Shack carries them for around $4.
Cheers,
levine
I don't care what anyone says, there *IS* a major problem with the Linux clock. I too have had the same problem with another distro. I wasted countless days trying to solve it, without success. My machine is dual booted with Windows (NO windows was not causing the problem!) and while the Linux boot had horrendously erratic time, Windows had no issues.
A month ago, I wiped the system and re-installed Linux. The problem went away but, now I have a different time problem. Now, my Linux clock runs slooowww when the systems is under any sort of a load. If the systems is left idle the clock keeps perfect time. Run Konqueror for a while and the clock goes to shit. Run an editor, doesn't seem to matter which, and the clock is worthless. Hell, let a screen saver run overnight and the clock loses 5 hours.
There is a problem with the clock!
UTC=false
Because Windows diddles with the hardware clock directly, it can't be used (directly) as a UTC time source for UNIX.
Naturally, if you're ONLY running Linux, you can have UTC=true and forget about it.
--
As many have already pointed out, once the OS successfully boots the responsibility of maintaining the current time transfers to the operating system. As a result of this transition, 'time drift' is completely possible - even common - on systems that maintain long up-times (e.g. *nix).
As the original question states, this offset in time is automatically corrected upon reboot. This is due to the OS once again keying off from the far more reliable internal hardware clock.
To me, the cause/solution to this individual's issue is quite apparent. The issue is caused by running far too stable of an operating system - LINUX. As such, the somewhat obvious solution to change the installed OS to something a bit, shall we say, less reliable.
Like many, when I think of unreliability I immediately think of Windows!!! May I suggest the ME version - in my very limited experience with this product, I have found it to be most unstable...your consequently, workstation will never go without a reboot for a long enough period to ever experience time drift again!!!
Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin
I'm not completely sure (as my Garmin is at home), but I believe the NMEA protocol includes timestamping. I'd be shocked if it doesn't.
It's not the microsecond accuracy that specially-designed GPS systems have, but it'll definately be accurate to within a few seconds.
Even a simple $99 Garmin eTrex could probably solve your problems, although you might want to go with a more expensive unit with an external antenna (maybe the eMap). Or you could buy one of the dedicated serial GPS modules, like the Garmin 35.
retrorocket.o not found, launch anyway?
Its doubtful that having an AMD processor is related. If it is, its indirectly. For example, that might be the issue because everyone building AMD chipsets use the same RTC circuit. Therefore, this is a problem. I have Intel processors in my computer and the clock plays funny tricks from time to time.
assuming your pc has a fairly often internet connection, turn on the time correction service in xp (its available from the time/date properties) and then go searching in the registry to change the time to something more frequent than once a week
(my laptop loses a lot of time, so i have xp synch the clock every 2 hours)
Need a Catering Connection
This is just a guess, but could your problems be related to apm or some other power management features? A bit over a year ago I was playing with apm on my Linux desktop. Whenever the computer went into a suspend or low-power mode, my clock would be completely messed up by several hours. I'm not sure if it was a bug on my motherboard, a bug in the apm code, or just that I'd misconfigured something. Either way, I just disabled all power management features (except using xset to turn off the monitor with dpms) and haven't had a problem since.
If you try this, you'll probably want to turn power management off both in software (remove apmd etc.) and in the motherboard's bios settings. Most motherboards should allow you to do this.
Good luck!
It's only software!
If you can get a digital signal on a CDMA-based cellphone from your basement, you might want to look into this horrifically-overpriced box.
The only time I've ever witnessed something like this was when I serviced a client who kept complaining about time jumps (usually backwards and in large hour chunks). I'd swapped all the hardware several times (motherboard, battery, processor, memory, all the ISA cards, etc).
Finally, I saw it happen. It was right about lunch time and on the other side of the wall was the worlds oldest radar range (pre Microwave Oven). That sucka kicked in when someone heated their lunch and the clock on the computer actually ran backwards!
I had to move the desk away from the wall several feet and the problem stopped happening.
More than likely though, the problem is with a buggy BIOS or dying battery. Replace the battery, flash your BIOS to the latest revision. If this doesn't work then you're only out about $10.00. Next step is to either buy an add-on time device that works properly or if you have a net connection running all the time, look into the NTP (Network Time Protocols) to sync with the Naval Observatory or another good source for correct time on as frequently a basis as you require.
Also check out the Linux clock features like the realtime daemon, it's not for realtime as in realtime OS but for more accurate time keeping. Red Hat has this daemon by default.
Check your security, make sure a co-worker is not just trying to mess with your head by changing your clock remotely.