Ever since the move to kernel 2.6.10, system time on my PC has been highly inaccurate (the hardware clock works fine). I do not have exact figures, by I'd say that it moves ahead about 5 minutes per hour. This did not occur with any previous kernels (2.6.8.1 and before, I did not check 2.6.9), and still happens after an upgrade to 2.6.11.
Relevant system specs:
Athlon XP 2600+
ASUS A7N8X-X (nForce2 chipset)
I can post the kernel configuration parameters, but I think there is nothing special there (I tried both the stock kernel provided by ARCH for general i686 processors, and my own compiled kernel). This is a desktop system, by the way.
I have searched the web in vain for similar problems reported by other people, but could come up with nothing. Is it a known problem? Can anyone suggest a fix, or a specific test I should run?
Thanks,
Elad
| Shared swap partition | 57 minutes ago | Linux general |
| high memory | 1 day ago | Linux kernel |
| semaphore access speed | 1 day ago | Applications and Utilities |
| the kernel how to power off the machine | 2 days ago | Linux kernel |
| Easter Eggs in windows XP | 2 days ago | Windows |
| Root password | 2 days ago | Linux general |
| Where/when DNOTIFY is used? | 2 days ago | Linux kernel |
| How to convert Linux Kernel built-in module into a loadable module | 2 days ago | Linux kernel |
| Linux 2.6.24 and I/O schedulers | 2 days ago | Linux kernel |
| USB Driver -- Interrupt Polling -- A Little Help Please | 2 days ago | Linux general |
Not seen here.
I have Athlon XP2800+ on Asus A7N8X-Deluxe-v2 (not -X). So, similar but not identical hardware. I am on 2.6.11. I see no problem, I just ran an 'ntpdate' which was last run about 23 hours ago, and the discrepancy was only 1.5 seconds.
Maybe you could run ntpdate (or a full ntpd) via cron in /etc/cron.hourly as a workaround, and log the time discrepancies each time, to see if it's a consistent error.
Will Smith
www.willsmith.org
Test results
Well, it seems that my initial numbers were somewhat exaggerated. I ran some tests through the night, and the drift is 25 seconds per hour (very consistent). This is still quite a visible (and annoying) discrepancy. The most important thing is that it has something to do with the move to kernel 2.6.10.
Elad
Same kind of problem
I have been noticing the same kind of problem on my Petium4 2.4ghz system, so I don't think this is AMD specific. I am running the E7205 workstation/server chipset, and I just resynced my clock to see it had drifted by about 16 minutes. I synced it about two days ago, and it was off by a few minutes then. I've been syncing my clock every day since I switched to 2.6.11.4 from 2.6.7. This is a very annoying problem. If anyone needs any info from my system to help fix this, just ask. I'll gladly supply it.
Can you run the same test I d
Can you run the same test I did, namely, launching ntpdate from an hourly cron script, and redirecting the output to a log file? It would be interesting to see what kind of drift-per-hour you get.
Elad
Same problem
I am having the same problem on both my Celeron-M laptop and Athlon-XP desktop with recent kernels. When I come home, I will check more exact timings, could be like 25 seconds per hour...
Why is this a problem?
Why is a system clock running at the wrong speed by a constant error a problem for you? This is exactly what ntpd resp. chrony (a more lightweight ntpd replacement) are designed for. They constantly run in the background, comparing the clock _speed_ with external clocks and using kernel services to adjust the system clock speed. This even works, if you are only sporadically connected to the internet, because to determine the speed, you only have to check at start and end of a time interval. (was your problem caused by a kernel ntp change perhaps? don't know...) Once determined and fed into the kernel, the speed factor is applied onto every time measurement: every timer tick some relatively expensive kernel internal ntp routines calculate the real time.
ntpdate on the other hand can't adjust the clock speed, because it is only a one-shot measurement.
If the speed difference is non-constant, you have a problem, though.
Only? That's quite a drift
Only? That's quite a drift
Hi I have a similar problem,
Hi
I have a similar problem, but the time is really really going too much fast!
Here is a video you can see:
http://www.majinken.com/clock.avi
I really don't know what to do :/
ASUS A7N8X
Hello,
I'm a bit late to the discussion but I can also confirm this problem. I have 3 ASUS A7N8X (various versions) that is showing the same 'fast clock' behaviour. All 3 systems are using the standard Ubuntu prepackaged 2.6.10 kernel. If I drop back to 2.6.8 the problem stops.
G.
I also have the same problem
I also have the same problem on an MSI motherboard with nforce2ultra, using the 2.6.11.8
Bandaid fix for clock problems with 2.6.8+
Well I've dropped back to Ubuntu's 2.6.8.1 kernel and the problem is still there but the drift is not as pronounced as it was with 2.6.10. With 2.6.10 - I was gaining 1 second every 90 seconds, with 2.6.8 - I gained a couple of minutes for the day.
I have installed ntpd on all 3 systems and am using the following /etc/ntp.conf
# /etc/ntp.conf, configuration for ntpd
# The following line will stop ntpd from crapping out if the drift is too great.
tinker panic 0 stepout 0
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
restrict default kod notrap nomodify nopeer noquery
restrict 127.0.0.1 nomodify
server pool.ntp.org
I hope this helps, until the problem can be solved.
G.
ASUS A7N8X-X system clock drift
I also had this problem on kernel 2.6.11.8 on my ASUS A7N8X-X motherboard. The system clock was about 5% faster than the hardware clock. This caused ntpd to be unable to synchronize properly.
I solved the problem by booting with the kernel options "acpi=off" and "noapic".
Hope this helps,
--Torsten Seemann
Also could be spread spectrum setting in BIOS
Although the "noapic acpi=off" option solved my "gaining 5 minutes and hour" problem, I also found this posting that says that smaller gains might be due to Spread Spectrum settings in the BIOS:
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/1505.html
--Torsten Seemann
Thanks. Setting the FSB Sprea
Thanks. Setting the FSB Spread Spectrum value to 0% has solved my problem.
Elad
Changing BIOS worked for me
Thanks a lot for posting that link about how to change the spread spectrum setting in the BIOS. My clock was galloping way too fast until I disabled the spread spectrum setting in the Advanced Chipset Features of my BIOS on my NVIDIA nForce2 motherboard.
ASUS clock 2.6.12 kernel way out
I have Ubuntu linux-amd64-k8-smp package which is 2.6.12.16-1 with Athlon 3800 x2 on ASUS SLI (nVidia chipset) and the clock is gaining MORE than 10 minutes per hour. However I just switched to non-SMP kernel and the problem seems to have gone away. Bios is configured for auto overclocking etc, power and voltage management. Hmm.
My system clock runs 5% fast,
My system clock runs 5% fast, and keypressses repeat sporadically, as you can see. 5% gain is far too much for ntpd to keep up with; it gives up. The gain rate is also uneven.
I don't have the ATI timer bug: I don't have an ATI chipset, and disable_timer_pin_1 and allll of the other suggested boot parameter fixes (noooapic, acpi=ooff, etc.) are ineffective. Although most people who had this problem seem to be able to solve it with disable_timer_pin_1, it doesn't solve the problem for me.
I have an Athlon64 X2 4400+ CPU, MSI K8N Neo4 Platinum mobo, running kernel 2.6.15 with SMP. I don't want to turn SMP off: I have a brand-new dual-core CPU!
Hmm
I wonder if this is a similar incarnation of the problem I had. View the descussion: http://kerneltrap.org/node/6258
could be...
Thanks, it sure looks similar. Following a suggestion there I've rebooted with clock=tsc. I'll know in a day or so if it helped. Other people (a LOT of people have had this or similar problems) have said to use 'notsc' and/or 'clock=pmtmr', but I've tried both of those and they didn't help.
Other suggestions in that thread:
* make usb use "Shadow(640k)" : this is a BIOS setting IIRC. Will check it when I'm at home.
* "enable MSI interrupts": wha? where? BIOS, or kernel?
* change the HZ clock from 250 (default) to 1000: I know this is a kernel option. I've wondered what difference it makes. Any potential bad effects?
Thanks,
A.
1000hz no effect
Setting your timing to 1000hz will probably not change anything. For me on 2.6.16 it actually made interactivity worse then my distro's default of 250hz. Performing several operations caused the mouse to jitter when moving it around.
fixed in 2.6.16
I upgraded my kernel to 2.6.16, and the problem has disappeared for me. Running more than a week now with no trace of clock instability or keyboard jitter.
I am using RHEL 4 (update 3)
I am using RHEL 4 (update 3) and their is lot of time difference between system clock and hardware clock.
Time
Im sorry for asking, I know this is only Linux forum. This is the only forum where are people describing this time problem. I have got Asus A7N8X-E Deluxe (NF2-U) board an Im running WinXP Prof (SP2). Yesterday my system time started gaining several minutes every hour. I tried to reinstall system - no change. BIOS clock - ok. No one helped me, maybe someone here can - please. PS: Sorry, my english isnt perfect.