| View previous topic :: View next topic |
| Author |
Message |
TinheadNed
Guru
Joined: 05 Apr 2003
Posts: 339
Location: Farnborough, UK
|
 Posted: Fri Aug 21, 2009 5:28 pm Post subject: TSC clocksource totally unstable in 2.6.30? |
 |
|
I upgraded from 2.6.29 to 2.6.30 at the weekend, and my 64-bit P4-based server started losing over an hour a day in time. NTP couldn't even keep up, the drift was larger than it could skew.
After a few days of not having enough time to do anything apart from ntpdate cron jobs, I sat down and had a look. hwclock reported that the battery-backed clock was keeping time fine. Contents of /sys/devices/system/clocksource/clocksource0/available_clocksource was "tsc hpet acpi_pm jiffies", and I set current_clocksource to hpet. No more drift.
There's no mention in the kernel boot about the tsc being unstable. I can't really reboot the machine much as it's a MythTV box as well, and WAF will drop if I reboot it "unnecessarily". |
|
| Back to top |
|
 |
doctork
Guru
Joined: 25 Apr 2004
Posts: 370
Location: Cleveland, OH
|
| Posted: Fri Aug 21, 2009 5:43 pm Post subject: |
|
|
I had the same problem, so I added a kernel parmater in grub.conf:
| Code: | | kernel /vmlinuz real_root=/dev/sda3 clocksource=hpet |
--
doc |
|
| Back to top |
|
|
cca
n00b
Joined: 07 Jun 2004
Posts: 38
Location: Greece
|
| Posted: Sat Aug 22, 2009 7:05 am Post subject: |
|
|
| doctork wrote: | I had the same problem, so I added a kernel parmater in grub.conf:
| Code: | | kernel /vmlinuz real_root=/dev/sda3 clocksource=hpet |
--
doc |
Discovered the exact same problem a week ago, solved it the same way too, set HPET as the clocksource stops the time drift. I also tried acpi_pm with the same horrible results as TSC. I'm using and AMD Phenom x3 processor running on 32 bits install. |
|
| Back to top |
|
|
TinheadNed
Guru
Joined: 05 Apr 2003
Posts: 339
Location: Farnborough, UK
|
| Posted: Sun Aug 23, 2009 4:40 pm Post subject: |
|
|
| Had to power off the machine this weekend, and now it's stable again on TSC. I don't understand what's changed at all. Perhaps a reboot for upgrading was the problem. Somehow? |
|
| Back to top |
|
|
hvengel
Guru
Joined: 19 Sep 2004
Posts: 515
|
| Posted: Fri Oct 30, 2009 7:13 pm Post subject: |
|
|
| cca wrote: | | doctork wrote: | I had the same problem, so I added a kernel parmater in grub.conf:
| Code: | | kernel /vmlinuz real_root=/dev/sda3 clocksource=hpet |
--
doc |
Discovered the exact same problem a week ago, solved it the same way too, set HPET as the clocksource stops the time drift. I also tried acpi_pm with the same horrible results as TSC. I'm using and AMD Phenom x3 processor running on 32 bits install. |
These newer AMD processors should have an invariant TSC (one that runs at the same speed regardless of the processor power management state changes) that runs either at the base clock speed (IE. 200MHz on most systems) or at the lowest multiplier speed (800MHz in many systems). It should be possible to set which of these is used in the BIOS. There has been some work in the kernel related to the new invariant TSC feature for these AMD processors but it appears that this might not be mature yet (please open a bug report on kernel.org). On the Intel side only I7 and newer processors have an invariant TSC. There are several time keeping related advantages to using the TSC counter (assuming that things function correctly):
1. Higher resolution (200MHz or 800MHz vs. 10Mhz or 25Mhz for HPET).
2. Lower latency - accessing the TSC counter is about 100 times as fast.
But these advantages may not be significant unless you are using a high precision local reference clock (gps, loran...) and to do that you currently need to run a LinuxPPS patched kernel. |
|
| Back to top |
|
|
|
Kernel & Hardware
