From: Monty <xiphmont@xiph.org>
To: Andi Kleen <ak@muc.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: large, spurious[?] TSC skews on AMD 760MPX boards
Date: Tue, 27 Jul 2004 18:38:53 -0400 [thread overview]
Message-ID: <20040727223853.GL14553@xiph.org> (raw)
In-Reply-To: <m3isc9mker.fsf@averell.firstfloor.org>
On Tue, Jul 27, 2004 at 07:26:04PM +0200, Andi Kleen wrote:
> xiphmont@xiph.org (Monty) writes:
>
> > Ever since getting my first dual Athlon, the system timer was 'not
> > quite right' when running at stock speed. Selects, alarms, etc, had a
> > strange way of firing fractions of a second or several seconds 'too
> > late'. I discovered that overclocking by about 10% made the problem
>
> That points away from the TSC actually. select and alarm use the jiffies
> clock, which is managed by the PIT timer in the southbridge. AFAIK
> they never rely on the TSC.
Although I believe you, the timer problem exists only when boot
reports the TSC skew.
> Assuming it is the TSC:
>
> You could write a multithreaded program that polls the TSCs
> on your both CPU for a long time and check out the drift rate.
> The kernel will try to fix it at boot time, but it cannot do that when the TSCs
> are drifting later.
Drift doesn't seem to be a problem; if the system boots without the
'skew' message, I have no timer difficulties even if the box is up for
months. If the system boots with a skew message, not a single
timer-based op on the machine seems to work ever; I can't watch
movies, play games or anything. I'll get a few frames, a freeze for
several seconds, a few seconds of frames, freeze for several seconds,
a frame or two, more freeze, etc... This appears to be related to
processor affinity (when the process gets bounced to the other CPU,
the timers appear to just freeze for a while or stop entirely).
> One way to work around it would be to boot with "notsc". This will
> make your gettimeofday() slower and more inaccurate though.
I will try that and report back.
> Assuming it is not:
>
> Something is wrong with your PIT timer in the southbridge. Maybe
> just run ntpd ?
I do run ntpd. My problem and concern is primarily with sub-second
timers having a granularity of several seconds.
> I know that later AMD chipsets - in particular the 8111 - are somewhat
> bad time keepers, which makes it a good idea to run NTP always.
The bug is all or nothing. Without the bootup skew report, the
machine runs flawlessly indefinitely.
Monty
next prev parent reply other threads:[~2004-07-27 22:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2kECV-3a0-3@gated-at.bofh.it>
2004-07-27 17:26 ` large, spurious[?] TSC skews on AMD 760MPX boards Andi Kleen
2004-07-27 22:38 ` Monty [this message]
2004-07-21 20:40 Monty
2004-07-22 13:09 ` Will S.
2004-07-22 18:12 ` Monty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040727223853.GL14553@xiph.org \
--to=xiphmont@xiph.org \
--cc=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.