You are not logged in.
Pages: 1
Hey guys, so this is kind of concerning. I was looking through my logs and I found that my system clock drifts by something like 5 seconds per minute:
Nov 20 21:00:54 asakura ntpd[1576]: adjusting local clock by -16.118286s
Nov 20 21:04:38 asakura ntpd[1576]: adjusting local clock by -16.066977s
Nov 20 21:07:45 asakura ntpd[1576]: adjusting local clock by -16.057939s
Nov 20 21:08:18 asakura ntpd[1576]: adjusting local clock by -16.015683s
Nov 20 21:12:30 asakura ntpd[1576]: adjusting local clock by -15.985421s
Nov 20 21:14:45 asakura ntpd[1576]: adjusting local clock by -15.967538s
Nov 20 21:16:23 asakura ntpd[1576]: adjusting local clock by -15.931567s
Nov 20 21:20:30 asakura ntpd[1576]: adjusting local clock by -15.901544s
Nov 20 21:23:06 asakura ntpd[1576]: adjusting local clock by -15.867335s
Nov 20 21:25:34 asakura ntpd[1576]: adjusting local clock by -15.819550s
Nov 20 21:29:46 asakura ntpd[1576]: adjusting local clock by -15.811125s
Nov 20 21:30:18 asakura ntpd[1576]: adjusting local clock by -15.796072s
Here's my rc.conf if it's applicable:
LOCALE="en_US.UTF-8"
HARDWARECLOCK="UTC"
TIMEZONE="America/Los_Angeles"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
Any idea on what could be causing this? Seems like something is terribly wrong here.
Last edited by FooSoft (2009-11-21 11:11:17)
Offline
I'm no expert here, but perhaps your CMOS battery isn't quite right? If you don't mind losing your BIOS settings, you can try putting in a new one and trying that. You could even try just pulling out the old one and putting it back in to see if resetting the BIOS works.
The human being created civilization not because of willingness but of a need to be assimilated into higher orders of structure and meaning.
Offline
I *believe* that dying CMOS battery usually leads to clock running slow. But it's worth a shot.
Another really strange thing I've discovered now is that as my computer stays on longer, it gets "better" at keeping track of time.
The drift seems to be much less now
Nov 21 14:52:40 asakura ntpd[1568]: adjusting local clock by -3.058754s
Nov 21 14:56:22 asakura ntpd[1568]: adjusting local clock by -2.991466s
Nov 21 14:59:35 asakura ntpd[1568]: adjusting local clock by -2.937058s
Nov 21 15:03:15 asakura ntpd[1568]: adjusting local clock by -2.900375s
Nov 21 15:04:23 asakura ntpd[1568]: adjusting local clock by -2.840415s
Nov 21 15:08:44 asakura ntpd[1568]: adjusting local clock by -2.769625s
However once I reboot, it will go up to -16 seconds again haha.
Offline
Weird. The hardware clock is only used when the machine is turned off to maintain the time. Upon boot the kernel reads the hardware clock and starts keeping track of time itself. If the CMOS battery is dying then the hardware clock *may* be running slow which would mean the kernel is starting with an incorrect time value. Not sure what would make the hardware clock run fast? You can check the hardware clock easily. Just turn off the machine with an accurate time and turn it on at a later time and check the time in the bios.
If you are running NTP any error should be corrected over time. I think NTP tries to avoid making relatively large changes to the system time so if the time is out by a significant amount in the hardware clock upon boot, it may take a while for it to adjust.
Last edited by mikesd (2009-11-21 23:48:23)
Offline
you need a new battery ,
I've got the same problem,Both the time and date value will change after a reboot
Offline
I just started getting this problem in the last day also. I left my computer over night, then started it, and it was running 30 minutes fast. Reset the clock, turned it off, came back 12 hours later and it's 20 minutes fast. Does it really make sense that this would be the CMOS battery?
Offline
As an added piece of information, I've been checking the harward clock with hwclock and just noticed that in the last hour it's gained 1 minute and 30 seconds, even with my laptop running. So the clock in Arch has the correct time. But the harward clock is gaining time.
Offline
I have the similar problem. I found the hwclock is changed because there is a command executed hourly in /etc/cron.hourly. The file named "adjtime". This command will update hwclock according to the system clock. But I don't know why system clock goes faster or slower.
Offline
Does removing /var/lib/hwclock/adjtime help?
Offline
I have the similar problem. I found the hwclock is changed because there is a command executed hourly in /etc/cron.hourly. The file named "adjtime". This command will update hwclock according to the system clock. But I don't know why system clock goes faster or slower.
So your system clock is running fast/slow? In my case the system clock is fine, once I set it to the correct time. But the hardware clock is consistently running fast; and then this messes up the system clock on reboot, giving it the incorrect time to start with.
Offline
Does removing /var/lib/hwclock/adjtime help?
Thanks for the suggestion. I removed this file and for the last hour the time has stayed correct.
So what sort of bug is going on here then? I don't really know what to do next. It looks like the file is regenerated whenever the system boots, so that will start the problem all over again. Is this a kernel bug? Should an Arch bug report be filed? About what component? Whatever's going on here is a bit beyond me.
Offline
Maybe let's just wait. Don't fiddle w/ anything time-related and check at least once a day for the next couple days if the date & time is OK.
Offline
My system clock is slower than real time. I changed adjtime file to update system clock according to hwclock , not the other way.
Offline
Maybe let's just wait. Don't fiddle w/ anything time-related and check at least once a day for the next couple days if the date & time is OK.
Yeah, now even though the system has regenerated the adjtime file, the hardware clock seems to be fine. At least I've been checking the hardware clock for the last hour and it has remained correct. Is it possible that the adjtime file just had some incorrect setting in it and letting the system regenerate the file automatically fixed the problem? Thanks again for the help, by the way.
My system clock is slower than real time. I changed adjtime file to update system clock according to hwclock , not the other way.
What did you change in the adjtime file to do this? Just curious.
Offline
Is it possible that the adjtime file just had some incorrect setting in it and letting the system regenerate the file automatically fixed the problem?
Yes. My clock was getting slower by about 27 mins/day, so I just deleted that file and it all works fine again.
Thanks again for the help, by the way.
You're welcome.
Offline
The original content of adjtime is :
/sbin/hwclock --adjust
now I changed it to :
/sbin/hwclock -s
Offline
Hmm, my adjtime only has this content:
0.000000 1259624253 0.000000
1259624253
LOCAL
So I could just add either line, I presume, to set which clock is used as the base time?
In any case, my clock does seem to be working fine now, after deleting the file and letting it regenerate.
Offline
I have also problem with clock but different one i think. I have Windows and Arch. No metter whether clock is set "localtime" or "UTC" it always wrong. Even when i set in BIOS or in Windows or in KDE it will always change after some time and display one hour backwards. Does anyone know the reason of that issue?
Offline
Are you sure you've tried all settings? I don't know anything about dualboot (you've mentioned Windows and KDE) but I've set the correct time in BIOS and my OS just stays on time. Poland is one hour "in front" of UTC, so your clock may be following UTC instead of CET. Remove '/var/lib/hwclock/adjtime' and see if it helps.
Offline
@karol I know it's strange but i'm observing this situation for a long time on my desktop and notebook. It could be ok for 2 months and suddenly the clock goes backward after evry reboot.
Offline
> It could be ok for 2 months and suddenly (...)
You know, we change our time in Poland twice a year ;-)
Offline
Pages: 1