Various users on this and other Linux forums have reported inaccuracy
in the Linux system clock when running on NVIDIA nForce2 hardware. This
inaccuracy is often characterized as "clock drift" or "noisiness", such
that the clock gains as much as twenty minutes per week. The problem is
evident when running in IOAPIC mode, with the programmable interval
timer
(PIT) interrupt routed through the IOAPIC. The problem is not evident
when the PIT interrupt is routed through the legacy PIC hardware.
A possible cause of this behavior is a clock synchronization issue that
can arise on some nForce2 systems when interrupts are routed through the
IOAPIC, and Spread Spectrum (SS) clocking is enabled. Under certain
conditions, this can cause the IOAPIC to issue multiple interrupts to
the CPU when it should have issued only one.
If you are experiencing clock inaccuracy on nForce2 hardware, take the
following steps to determine if this issue may be the cause:
1. Determine if the hardware you are using may be affected by this
problem. The problem is limited to MCP2 and MCP2-T hardware; it does
not affect MCP2-S or any nForce3 hardware. MCP2 and MCP2-T hardware
may be identified by the PCI device ID of the ISA bridge, which is
0x0060 for these devices.
To read the bridge device ID, use 'lspci -n -s 0:1.0' . The output
should be of the form '0000:00:01.0 Class 0601: 10de:0060 (rev a3)'.
The device ID of the bridge in this example is "0060" following the
NVIDIA PCI vendor ID "10de".
If your ISA bridge device ID is not 0x0060, then this issue is not
the cause of any clock inaccuracy you are experiencing.
2. Otherwise, examine the output from 'cat /proc/interrupts'. If IRQ0
(the timer) is shown to be in PIC mode rather than IOAPIC mode, then
this issue is not the cause of any clock inaccuracy you are
experiencing.
3. Otherwise, reboot your system and enter BIOS SETUP. Check if your
BIOS has a Front Side Bus (FSB) Spread Spectrum (SS) clocking option.
On many systems, this option is located in the "Advanced Chipset
Features" menu. If the option is present and enabled, disable it.
Boot Linux and observe the system clock over several hours to verify
if this has improved its accuracy.
Regards
Andy
--
Andy Currid, NVIDIA Corporation
[email protected]
On Wed, 2004-10-13 at 16:30, Andy Currid wrote:
> A possible cause of this behavior is a clock synchronization issue that
> can arise on some nForce2 systems when interrupts are routed through the
> IOAPIC, and Spread Spectrum (SS) clocking is enabled. Under certain
> conditions, this can cause the IOAPIC to issue multiple interrupts to
> the CPU when it should have issued only one.
>
> If you are experiencing clock inaccuracy on nForce2 hardware, take the
> following steps to determine if this issue may be the cause:
>
> 1. Determine if the hardware you are using may be affected by this
> problem. The problem is limited to MCP2 and MCP2-T hardware; it does
> not affect MCP2-S or any nForce3 hardware. MCP2 and MCP2-T hardware
> may be identified by the PCI device ID of the ISA bridge, which is
> 0x0060 for these devices.
>
> To read the bridge device ID, use 'lspci -n -s 0:1.0' . The output
> should be of the form '0000:00:01.0 Class 0601: 10de:0060 (rev a3)'.
> The device ID of the bridge in this example is "0060" following the
> NVIDIA PCI vendor ID "10de".
>
> If your ISA bridge device ID is not 0x0060, then this issue is not
> the cause of any clock inaccuracy you are experiencing.
lspci -n -s 0:1.0
output: 0000:00:01.0 Class 0601: 10de:0060 (rev a3)
>
> 2. Otherwise, examine the output from 'cat /proc/interrupts'. If IRQ0
> (the timer) is shown to be in PIC mode rather than IOAPIC mode, then
> this issue is not the cause of any clock inaccuracy you are
> experiencing.
>
cat /proc/interrupts
output: 0: 179117760 IO-APIC-edge timer
> 3. Otherwise, reboot your system and enter BIOS SETUP. Check if your
> BIOS has a Front Side Bus (FSB) Spread Spectrum (SS) clocking option.
> On many systems, this option is located in the "Advanced Chipset
> Features" menu. If the option is present and enabled, disable it.
> Boot Linux and observe the system clock over several hours to verify
> if this has improved its accuracy.
>
Both Front Side Bus and AGP spread spectrum are disabled.
The system is running 2.6.9-rc4 and has been up for 2 days. I'm showing
an offset of -32 seconds and growing.
Jesse
--
Jesse Stockall <[email protected]>
On Wednesday 13 October 2004 17:10, Jesse Stockall wrote:
>On Wed, 2004-10-13 at 16:30, Andy Currid wrote:
>> A possible cause of this behavior is a clock synchronization issue
>> that can arise on some nForce2 systems when interrupts are routed
>> through the IOAPIC, and Spread Spectrum (SS) clocking is enabled.
>> Under certain conditions, this can cause the IOAPIC to issue
>> multiple interrupts to the CPU when it should have issued only
>> one.
>>
>> If you are experiencing clock inaccuracy on nForce2 hardware, take
>> the following steps to determine if this issue may be the cause:
>>
>> 1. Determine if the hardware you are using may be affected by this
>> problem. The problem is limited to MCP2 and MCP2-T hardware; it
>> does not affect MCP2-S or any nForce3 hardware. MCP2 and MCP2-T
>> hardware may be identified by the PCI device ID of the ISA bridge,
>> which is 0x0060 for these devices.
>>
>> To read the bridge device ID, use 'lspci -n -s 0:1.0' . The
>> output should be of the form '0000:00:01.0 Class 0601: 10de:0060
>> (rev a3)'. The device ID of the bridge in this example is "0060"
>> following the NVIDIA PCI vendor ID "10de".
>>
>> If your ISA bridge device ID is not 0x0060, then this issue is
>> not the cause of any clock inaccuracy you are experiencing.
>
>lspci -n -s 0:1.0
>
>output: 0000:00:01.0 Class 0601: 10de:0060 (rev a3)
>
>> 2. Otherwise, examine the output from 'cat /proc/interrupts'. If
>> IRQ0 (the timer) is shown to be in PIC mode rather than IOAPIC
>> mode, then this issue is not the cause of any clock inaccuracy you
>> are experiencing.
>
>cat /proc/interrupts
>
>output: 0: 179117760 IO-APIC-edge timer
>
>> 3. Otherwise, reboot your system and enter BIOS SETUP. Check if
>> your BIOS has a Front Side Bus (FSB) Spread Spectrum (SS) clocking
>> option. On many systems, this option is located in the "Advanced
>> Chipset Features" menu. If the option is present and enabled,
>> disable it. Boot Linux and observe the system clock over several
>> hours to verify if this has improved its accuracy.
>
>Both Front Side Bus and AGP spread spectrum are disabled.
>
>The system is running 2.6.9-rc4 and has been up for 2 days. I'm
> showing an offset of -32 seconds and growing.
>
>Jesse
This, given the accuracy of the clock crystals used in todays
motherboard is not surprising. For that reason I run ntpdate 4x a
day, which keeps me within a second *most* of the time.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
> The system is running 2.6.9-rc4 and has been up for 2 days. I'm showing
> an offset of -32 seconds and growing.
That's -185 ppm (parts per million) error, or -0.0185%.
Typical cheap quartz crystals are +/- 100 ppm, but there are some cheaper
than that, and ceramic resonators like
http://www.ecsxtal.com/cerares.htm
I know Dave Mills learned from experience that the original +/-100 ppm
specs in NTP weren't wide enough and he had to change it to cope with
+/-500 ppm error in some clocks.
It *could* just be your motherboard's clock source.
On Wed, 2004-10-13 at 21:27, [email protected] wrote:
> > The system is running 2.6.9-rc4 and has been up for 2 days. I'm showing
> > an offset of -32 seconds and growing.
>
> That's -185 ppm (parts per million) error, or -0.0185%.
>
> Typical cheap quartz crystals are +/- 100 ppm, but there are some cheaper
> than that, and ceramic resonators like
> http://www.ecsxtal.com/cerares.htm
>
> I know Dave Mills learned from experience that the original +/-100 ppm
> specs in NTP weren't wide enough and he had to change it to cope with
> +/-500 ppm error in some clocks.
>
> It *could* just be your motherboard's clock source.
possible but....
a) When I boot without 'acpi_skip_timer_override' and I fall back to
using ExtINT for the timer there is no drift.
b) I rebooted and set FSB spread spectrum to 1.0 and let the machine run
over night. In 10 hours of uptime I'm off -45 seconds and growing. This
is -0.125%. So clearly having spread spectrum enabled does affect the
clock.
Thanks
Jesse
--
Jesse Stockall <[email protected]>