mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* 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 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
* 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®