* Re: Clock inaccuracy seen on NVIDIA nForce2 systems
@ 2004-10-14 1:27 linux
2004-10-14 12:09 ` Jesse Stockall
0 siblings, 1 reply; 6+ messages in thread
From: linux @ 2004-10-14 1:27 UTC (permalink / raw)
To: stockall; +Cc: linux-kernel
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clock inaccuracy seen on NVIDIA nForce2 systems
2004-10-14 1:27 Clock inaccuracy seen on NVIDIA nForce2 systems linux
@ 2004-10-14 12:09 ` Jesse Stockall
0 siblings, 0 replies; 6+ messages in thread
From: Jesse Stockall @ 2004-10-14 12:09 UTC (permalink / raw)
To: linux; +Cc: linux-kernel, ACurrid
On Wed, 2004-10-13 at 21:27, linux@horizon.com 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 <stockall@magma.ca>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clock inaccuracy seen on NVIDIA nForce2 systems.
@ 2004-10-14 13:44 Francois Meyer
0 siblings, 0 replies; 6+ messages in thread
From: Francois Meyer @ 2004-10-14 13:44 UTC (permalink / raw)
To: linux-kernel
> 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.
As it has been said, this could be due to just a
poor quality crystal. In addition, non temperature-
controlled crystals are far more efficient as
thermometers than as oscillators, as frequency is
directly and more than significantly depending on
crystal temperature.
Now if you think there is a real software issue
behind your observations, it wont be that easy to
distinguish between crystal and soft contributions,
unless the specifications of the crystal used on
those boards are far better than the drifts you
observed.
If the specs are of the same order, I think reliable
conclusions can only arise from tests issued on the
same physical hardware.
-- Francois Meyer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clock inaccuracy seen on NVIDIA nForce2 systems
2004-10-13 21:10 ` Jesse Stockall
@ 2004-10-14 0:45 ` Gene Heskett
0 siblings, 0 replies; 6+ messages in thread
From: Gene Heskett @ 2004-10-14 0:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Jesse Stockall, Andy Currid
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clock inaccuracy seen on NVIDIA nForce2 systems
2004-10-13 20:30 Andy Currid
@ 2004-10-13 21:10 ` Jesse Stockall
2004-10-14 0:45 ` Gene Heskett
0 siblings, 1 reply; 6+ messages in thread
From: Jesse Stockall @ 2004-10-13 21:10 UTC (permalink / raw)
To: Andy Currid; +Cc: Linux Kernel Mailing List
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 <stockall@magma.ca>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Clock inaccuracy seen on NVIDIA nForce2 systems
@ 2004-10-13 20:30 Andy Currid
2004-10-13 21:10 ` Jesse Stockall
0 siblings, 1 reply; 6+ messages in thread
From: Andy Currid @ 2004-10-13 20:30 UTC (permalink / raw)
To: Linux Kernel Mailing List
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
acurrid@nvidia.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-10-14 13:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-14 1:27 Clock inaccuracy seen on NVIDIA nForce2 systems linux
2004-10-14 12:09 ` Jesse Stockall
-- strict thread matches above, loose matches on Subject: below --
2004-10-14 13:44 Francois Meyer
2004-10-13 20:30 Andy Currid
2004-10-13 21:10 ` Jesse Stockall
2004-10-14 0:45 ` Gene Heskett
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®