Timedirft between system clock and hwclock

[Henry Ritzlmayr]

Am Donnerstag, den 10.05.2007, 10:06 -0300 schrieb John DeDourek:
> Henry Ritzlmayr wrote:
> > ... kernel: Your time source seems to be instable or 
> 
> > some driver is hogging interupts
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This would be my first guess.  The timer mechanism stores only one pending
> interrupt.  Thus, if the clock interrupt occurs twice while some driver has
> interrupts locked out, you typically get only one increment of time and the
> system time, which is just the sum of the increments falls behind.
> 
> This is made worse by the current standard kernels which have upped the
> clock rate from 100 interrupts per second to 250 or more.  At 100 interrupts
> per second, a device driver needs to lock out interrupts for 10 ms. before a
> timer tick is lost.  At 1000 interrupts per second, any driver that locks
> out interrupts for more than 1ms will cause a timer interrupt loss.
> 
> Since driver code runs slower on slower CPUs, this problem also occurs more
> often on slower CPUs.
> 
> I would first check whether there is a kernel boot parameter to set the 
> clock
> timer rate (often called Hz.).  If so, modify the kernel boot line to 
> set the timer
> rater to 100 Hz. and see if that helps.  If it does, then the above 
> describes the
> likely cause.  (Unfortunately, I am not an expert on kernel boot parameters,
> so I don't know the answer to this.)

I checked this already and didn´t find such - but I will continue
searching.

> 
> You may next want to try to identify which device driver is causing the 
> troubles.
> If there are device drivers that run devices that you can temporarily 
> live without,
> e.g. a webcam, try running without that device, either by unplugging it 
> or by
> modifying the module loading system to prevent that from happening.  
> (Unfortunately,
> I am not an expert so I can't tell you the best way to do that.)  Also 
> try running
> without your network driver loaded (not a lot of fun, so just for a 
> trial) and see
> if the problem corrects itself.  Of course if the problem is with the 
> hard drive
> driver or video driver there's not a lot you can do about it.  (Although 
> if you know
> how to drive Linux from the command line, like us old Unix junkies, you 
> could
> boot into run level 3, by adding a 3 to the boot command line.  That 
> would run
> your screen as a simple command window, eliminating a lot of driver overhead
> for running the GUI.  Maybe not fun, but you could at least see if the 
> problem
> goes away, which would tend to implicate the video driver as the one hogging
> the interrupts.)

Since I am one of those junkies the system runs at runlevel 3 anyway.
This is going to be my little server - so there are no webcams and other
fancy stuff - only Disks (raid), lots of unused USBs, one DVD-Drive and
the network of course. I will try disabling the network and see what
happens.

> You might try posting:
> -- the speed (MHz) and type of your processor
Intel E6600 @ 2.40GHz 

> -- the type of video board/chip and the driver you're running for that
No extra video board only the built in one - see below

$ lspci 

00:00.0 Host bridge: Intel Corporation 82Q963/Q965 Memory Controller Hub
(rev 02)
00:01.0 PCI bridge: Intel Corporation 82Q963/Q965 PCI Express Root Port
(rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965
Integrated Graphics Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network
Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
#2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
#1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HO (ICH8DO) LPC Interface
Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) SATA AHCI
Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller
(rev 02)

> -- the kernel you're running (uname -r)

I tried any I could still find on the net from 
kernel-2.6.18-1.2798.fc6.x86_64 to 
kernel-2.6.20-1.2948.fc6.x86_64
and every 64bit kernel shows this behavior. 

In the meantime I also tried FC7t4 (F7t4) and the newest kernel from
devel.
kernel-2.6.21-1.3116.fc7.x86_64
kernel-2.6.20-1.3104.fc7.x86_64

The good news ist - both of them work fine
and /sys/devices/system/clocksource/clocksource0/available_clocksource
now have tsc, hpet, acpi_pm and jiffies. 
the default chosen one is tsc 

So I have the option now to wait until F7 comes out or find the
cause/solution for the FC6 kernels. Since I am going to run
vmware-server on the machine I would prefer to stick with the 2.6.18
kernel from FC6 since the newer kernels don´t harmonize with
vmware-server very well. But maybe this will/is also solved within F7
kernels by that time. 

I will still "play" with the FC6-Kernels for the next days, and if
everything fails try to get vmware-server running with F7t4.  

Thanks for the hints - I will try them and if anybody else has ideas you
are very very welcome to .....

Henry