From: "Paul Rolland" <rol@witbe.net>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
rol@witbe.net
Subject: Re: constant_tsc and TSC unstable
Date: Fri, 30 Nov 2007 07:59:32 +0100 [thread overview]
Message-ID: <20071130075932.7f1f0974@tux.DEF.witbe.net> (raw)
In-Reply-To: <474F2E97.5080802@msgid.tls.msk.ru>
Hello,
On Fri, 30 Nov 2007 00:26:47 +0300
Michael Tokarev <mjt@tls.msk.ru> wrote:
> H. Peter Anvin wrote:
> > Paul Rolland (ポール・ロラン) wrote:
> []
> >> Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock.
> >> Marking TSC unstable due to: check_tsc_sync_source failed.
> []
> >> but I was wondering if this is a bug or a feature ;)
>
> > The problem you're having is that the TSCs of your two cores are
> > completely different, over a second apart. This is a bug, unrelated to
> > constant_tsc.
>
> A bug in where - in the CPU or in kernel?
Good question !
> The thing is that all our dual-core machines shows something like
> that.
>
> (not that huge difference as Paul reported, but still "unstable".
> The same happens with 2.6.23)
I've been checking my logs, and the difference is quite constant and
huge :
[root@tux log]# grep 'cycles TSC warp' messages*
messages:Nov 26 08:27:56 tux kernel: Measured 4078687691 cycles TSC warp between C
PUs, turning off TSC clock.
messages:Nov 26 17:21:21 tux kernel: Measured 3978592228 cycles TSC warp between C
PUs, turning off TSC clock.
messages.1:Nov 18 22:52:23 tux kernel: Measured 4063102940 cycles TSC warp between
CPUs, turning off TSC clock.
messages.1:Nov 19 07:19:02 tux kernel: Measured 4057192061 cycles TSC warp between
CPUs, turning off TSC clock.
messages.1:Nov 23 20:50:12 tux kernel: Measured 4064589321 cycles TSC warp between
CPUs, turning off TSC clock.
messages.2:Nov 12 08:06:44 tux kernel: Measured 4072130361 cycles TSC warp between
CPUs, turning off TSC clock.
messages.2:Nov 13 19:42:47 tux kernel: Measured 4049899451 cycles TSC warp between
CPUs, turning off TSC clock.
messages.2:Nov 17 09:27:22 tux kernel: Measured 4066629060 cycles TSC warp between
CPUs, turning off TSC clock.
messages.3:Nov 5 08:25:08 tux kernel: Measured 4086386109 cycles TSC warp between
CPUs, turning off TSC clock.
messages.3:Nov 8 13:07:08 tux kernel: Measured 4041945934 cycles TSC warp between
CPUs, turning off TSC clock.
messages.3:Nov 9 23:31:24 tux kernel: Measured 4092303059 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Oct 29 07:28:23 tux kernel: Measured 4096946373 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Oct 31 17:07:21 tux kernel: Measured 4046765372 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Oct 31 17:15:09 tux kernel: Measured 4039328228 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Oct 31 23:19:00 tux kernel: Measured 4069714246 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Nov 1 20:33:02 tux kernel: Measured 4088199726 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Nov 2 11:53:17 tux kernel: Measured 4079927527 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Nov 3 09:37:16 tux kernel: Measured 4071112656 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Nov 3 10:51:29 tux kernel: Measured 3986266219 cycles TSC warp between
CPUs, turning off TSC clock.
messages.4:Nov 4 18:14:56 tux kernel: Measured 4074214144 cycles TSC warp between
CPUs, turning off TSC clock.
> Note that once TSC is disabled (it's using "jiffies" as far
> as I can see), ntpd constantly speeds up and slows down the
> clock, it jumps +/- 0.5sec every several minutes or hours -
> I guess that's when ntpd process gets moved from one core
> to another for whatever reason. And an interesting thing
> is that with 64bits kernel this TSC problem does not occur
> on this very machine.
Hmmmm.... That could make it a problem related to kernel rather than CPU.
> Something similar is reported on AMD X2 64 machines as well --
> can't check right now.
If I recall correctly, issues with AMD X2 where related to TSC being
independant for each core and not constant (speed depending of C state).
But the reason I raise the issue is that the Core2 reports constant TSC,
so there is (IMHO) no reason for that.
Paul
next prev parent reply other threads:[~2007-11-30 6:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-29 16:11 Paul Rolland
2007-11-29 19:04 ` H. Peter Anvin
2007-11-29 21:26 ` Michael Tokarev
2007-11-30 6:59 ` Paul Rolland [this message]
2007-11-30 7:04 ` H. Peter Anvin
2007-11-29 21:36 ` Patrick McHardy
2007-11-29 23:29 ` Pallipadi, Venkatesh
2007-11-30 6:52 ` Paul Rolland (ポール・ロラン)
2007-12-06 0:35 ` Pallipadi, Venkatesh
2007-11-30 0:30 ` Frans Pop
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=20071130075932.7f1f0974@tux.DEF.witbe.net \
--to=rol@witbe.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjt@tls.msk.ru \
/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
Powered by JetHome