Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is a follow-up to my question yesterday, linked below.

I have a Fedora 10 box. When it is freshly rebooted, it keeps time very well. I test this by typing date, then enter, wait about a second, up arrow, enter, etc. to see if the seconds increment by 1 for each of my perceived seconds. So, it seems to work. Some time in the future, 14-48 hours later, I notice the timestamps on emails are screwy. New emails are dated like 6 hours ago. I log in to the box, do the date/up arrow/repeat thingy, and now it takes anywhere from 4-10 seconds for the seconds to increment by one.

Someone suggested using ntpd. I did that yesterday, and tonight, the time is screwed up again. ntpd was still running. Restarting ntpd had no effect. Shutting down ntpd, then running ntpdate sync'd the date to the correct time, but the seconds still did not increment by one for every second. I really don't have a clue what could be doing this to my system. Any suggestions are greatly appreciated. I don't want to run reboot as a cron job to fix this, I'll never get any uptime bragging rights that way.

Yesterday's thread: http://serverfault.com/questions/65386/linux-box-time-dilation

Thanks for reading and for any help.

share|improve this question

3 Answers 3

It sounds like the problem is not with your machine, but with whatever Linux is relying upon to keep time. Try a kernel command line argument like clocksource=hpet. Other common sources are tsc and acpi_pm.

Finally, try the notsc kernel command line argument.

share|improve this answer
    
Alternatively, check the timeservers listed in /etc/ntp.conf - the default is just to use the local clock, which will do you no good at all if that's what's faulty. –  RainyRat Sep 16 '09 at 11:21
    
Good idea. It does sound like Linux is using TSC on a CPU with variable TSC and power saving modes. –  Zan Lynx Sep 16 '09 at 14:35
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

What is the output? You can try to change the clocksource by using kernel boot options, or you can try to completely disable it with the notsc option.

Anyhow, this really sounds like faulty hardware

share|improve this answer
    
[me@host ~]$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc jiffies [me@host ~]$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc –  originalgeek Sep 16 '09 at 16:27
    
try to switch to jiffies, might be better. hpet is not bad either, but you have to install it –  dyasny Sep 16 '09 at 19:58

When it's gone bad can you run vmstat?

$ vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 4  0  56464 557284 289208 2132264    0    0     3    16   24   15 16  5 79  0
 0  0  56464 557508 289208 2132264    0    0     0    14 1146 2111  9  4 88  0
 1  0  56464 557540 289208 2132264    0    0     0     0 1170 2167  5  4 91  0
 0  0  56464 557172 289208 2132264    0    0     0    29 1213 2325  7  6 88  0
 2  0  56464 557876 289208 2132264    0    0     0    31 1261 2644 10  6 83  0

Look at the "in" column to see interrupts. I've seen broken hardware cause lots of interrupts which can mean that you don't get updates to the clock before.

Try booting it from a "Knoppix" cd and leave it for a while. Does the clock still go awry?

share|improve this answer
    
I'll check it next time. I am currently getting between 0 and 2000 interrupts per second, with occasional spikes up to 4500. How do I identify which interrupt request is saturating the system? This system basically runs headless, so the only sources should be the timer NIC, and the RAID controller. –  originalgeek Sep 16 '09 at 16:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.