From: "Pádraig Brady" <P@draigBrady.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Lee Revell <rlrevell@joe-job.com>, Andi Kleen <ak@suse.de>,
thockin@hockin.org, Luca Tettamanti <kronos.it@gmail.com>,
linux-kernel@vger.kernel.org, john stultz <johnstul@us.ibm.com>
Subject: Re: AMD X2 unsynced TSC fix?
Date: Tue, 31 Oct 2006 11:12:47 +0000 [thread overview]
Message-ID: <45472FAF.6080704@draigBrady.com> (raw)
In-Reply-To: <20061028052837.GC1709@1wt.eu>
Willy Tarreau wrote:
> On Fri, Oct 27, 2006 at 11:28:00PM -0400, Lee Revell wrote:
>
>>On Fri, 2006-10-27 at 18:04 -0700, Andi Kleen wrote:
>>
>>>I don't think it makes too much sense to hack on pure RDTSC when
>>>gtod is fast enough -- RDTSC will be always icky and hard to use.
>>
>>I agree FWIW, our application would be happy to just use gtod if it
>>wasn't so slow on these machines.
>
>
> Agreed, I had to turn about 20 dual-core servers to single core because
> the only way to get a monotonic gtod made it so slow that it was not
> worth using a dual-core. I initially considered buying one dual-core
> AMD for my own use, but after seeing this, I'm definitely sure I won't
> ever buy one as long as this problem is not fixed, as it causes too
> many problems.
For the record, in my previous job we were implementing
a very fast packet sniffer/timestamper using 2x3.2GHz P4 Xeons + linux 2.4.20 (with gtod)
Very rarely we would see inter packet times jump by (2^32)/CPU_Hz seconds,
when sniffing about 1.2 million packets per second on 2 e1000 links,
which suggested a wrap around of a 32 bit comparison somewhere.
This lead to the fix below which was never picked up
(I guessed because it was addressed elsewhere?).
Note we were only interested in millisecond resolution for the timestamps,
but the approximation is very good in general as you know the TSCs are very
close to each other when this condition happens.
Note power management was not used on our systems.
Pádraig.
diff -Naru linux-2.4.20/arch/i386/kernel/time.c linux-2.4.20-corvil/arch/i386/kernel/time.c
--- linux-2.4.20/arch/i386/kernel/time.c 2002-11-28 23:53:09.000000000 +0000
+++ linux-2.4.20-pb/arch/i386/kernel/time.c 2005-07-07 10:32:34.000000000 +0100
@@ -94,6 +94,9 @@
/* .. relative to previous jiffy (32 bits is enough) */
eax -= last_tsc_low; /* tsc_low delta */
+ if ((signed)eax < 0) { /* workaround for drifting TSCs */
+ eax = 0;
+ printk(KERN_INFO "tsc wrap around applied\n"); /* rare */
+ }
/*
* Time offset = (tsc_low delta) * fast_gettimeoffset_quotient
next prev parent reply other threads:[~2006-10-31 11:13 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-27 17:15 AMD X2 unsynced TSC fix? Lee Revell
2006-10-27 20:18 ` Luca Tettamanti
2006-10-27 23:04 ` thockin
2006-10-28 0:00 ` Luca Tettamanti
2006-10-28 0:17 ` Lee Revell
2006-10-28 2:46 ` thockin
2006-10-28 3:59 ` Andi Kleen
2006-10-28 6:32 ` thockin
2006-10-28 9:14 ` Vojtech Pavlik
2006-10-28 18:22 ` Lee Revell
2006-10-28 19:57 ` Vojtech Pavlik
2006-10-28 22:54 ` thockin
2006-10-28 1:04 ` Andi Kleen
2006-10-28 3:28 ` Lee Revell
2006-10-28 5:28 ` Willy Tarreau
2006-10-28 18:08 ` Lee Revell
2006-10-28 19:14 ` thockin
2006-10-30 17:22 ` Langsdorf, Mark
2006-10-28 18:37 ` Andi Kleen
2006-10-28 19:15 ` Willy Tarreau
2006-10-28 19:18 ` thockin
2006-10-28 19:32 ` Willy Tarreau
2006-10-28 19:42 ` thockin
2006-10-28 20:16 ` Willy Tarreau
2006-10-28 19:33 ` Andi Kleen
2006-10-28 20:04 ` Willy Tarreau
2006-10-28 20:11 ` Andi Kleen
2006-10-28 20:36 ` Willy Tarreau
2006-10-29 1:28 ` Lee Revell
2006-10-28 21:00 ` Lee Revell
2006-10-31 11:12 ` Pádraig Brady [this message]
2006-10-31 15:31 ` Willy Tarreau
2006-10-30 20:30 ` Christoph Lameter
2006-10-27 20:35 ` Andi Kleen
2006-10-27 20:41 ` Lee Revell
2006-10-27 21:48 ` Chris Friesen
2006-10-27 22:08 ` Lee Revell
2006-10-28 3:58 ` Sergio Monteiro Basto
2006-10-28 4:06 ` Andi Kleen
2006-10-28 4:22 ` Sergio Monteiro Basto
2006-10-30 3:10 ` Sergio Monteiro Basto
2006-10-30 15:23 ` Andi Kleen
[not found] ` <1162253008.2999.9.camel@localhost.portugal>
2006-10-31 0:14 ` Lee Revell
2006-10-31 0:25 ` john stultz
2006-10-31 2:41 ` Siddha, Suresh B
2006-10-31 15:05 ` Sergio Monteiro Basto
2006-11-01 1:46 ` Sergio Monteiro Basto
2006-11-01 2:44 ` Siddha, Suresh B
2006-11-08 0:22 ` Sergio Monteiro Basto
2006-11-08 19:53 ` Thomas Gleixner
2006-11-09 0:39 ` Sergio Monteiro Basto
2006-11-09 1:13 ` john stultz
2006-11-09 1:27 ` Sergio Monteiro Basto
2006-11-15 1:51 ` Sergio Monteiro Basto
[not found] ` <20061115193514.41C01102C011@mail.goron.de>
2006-11-16 1:38 ` Sergio Monteiro Basto
2006-11-16 1:45 ` Sergio Monteiro Basto
2006-10-28 6:35 ` thockin
2006-10-28 6:46 ` Andrew Morton
2006-10-28 6:49 ` thockin
2006-10-28 7:13 ` Andrew Morton
2006-10-28 7:25 ` thockin
2006-10-28 9:46 ` Andi Kleen
2006-10-28 9:45 ` Andi Kleen
2006-10-28 9:48 ` Andi Kleen
2006-10-27 21:58 ` Friedrich Göpel
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=45472FAF.6080704@draigBrady.com \
--to=p@draigbrady.com \
--cc=ak@suse.de \
--cc=johnstul@us.ibm.com \
--cc=kronos.it@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
--cc=thockin@hockin.org \
--cc=w@1wt.eu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox