Hello,
I noticed that the bogomips results for the two cores on my machine are
consistently not the same, the second one is always reported slightly
faster, it's a small difference and I saw the same in a posted dmesg from
somebody else on the list. Which made me wonder:
Shouldn't they be the same, as the cores run from the same clock?
Could it be a bug in the bogomips calculation which could make some of the
short time-out stuff fail?
Could this be related to the tsc synchronisation stuff mentioned in the
lost ticks - TSC timer thread?
Regards,
Robert Boermans.
PS nothing actually fails on my system because of this, I just thought it
was odd. Although I do sometimes get the clock runs at double speed
problem but only after at least one day uptime, but I reboot most days for
games anyway.
On Wednesday 21 September 2005 16:20, [email protected] wrote:
> Hello,
>
> I noticed that the bogomips results for the two cores on my machine are
> consistently not the same, the second one is always reported slightly
> faster, it's a small difference and I saw the same in a posted dmesg from
> somebody else on the list. Which made me wonder:
I guess it's a cache warming effect. Please show the numbers.
--
vda
Denis Vlasenko <[email protected]>
21/09/2005 14:27
To
[email protected]
cc
[email protected]
Subject
Re:
On Wednesday 21 September 2005 16:20, [email protected] wrote:
> Hello,
>
> I noticed that the bogomips results for the two cores on my machine are
> consistently not the same, the second one is always reported slightly
> faster, it's a small difference and I saw the same in a posted dmesg
from
> somebody else on the list. Which made me wonder:
I guess it's a cache warming effect. Please show the numbers.
--
vda
Probably not, got this one from a web site, and on this one the first core
seems to be faster (can't check my own machine it's off and at home and
I'm at work.) The difference I get is similar, but always with the second
one faster. It's the same when using cat on /proc/cpuinfo. Oh and I saw it
on 2.6.11 and 2.6.12 as supplied with fedora core 4 myself.
Calibrating delay using timer specific routine.. 4014.73 BogoMIPS
(lpj=8029470)
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0(2) -> Core 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 4005.37 BogoMIPS
(lpj=8010751)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1(2) -> Core 1
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Total of 2 processors activated (8020.11 BogoMIPS).
> > I noticed that the bogomips results for the two cores on my machine are
> > consistently not the same, the second one is always reported slightly
> > faster, it's a small difference and I saw the same in a posted dmesg
> from
> > somebody else on the list. Which made me wonder:
>
> I guess it's a cache warming effect. Please show the numbers.
>
> Probably not, got this one from a web site, and on this one the first core
> seems to be faster (can't check my own machine it's off and at home and
> I'm at work.) The difference I get is similar, but always with the second
> one faster. It's the same when using cat on /proc/cpuinfo. Oh and I saw it
> on 2.6.11 and 2.6.12 as supplied with fedora core 4 myself.
>
> Calibrating delay using timer specific routine.. 4014.73 BogoMIPS
> (lpj=8029470)
...
> Initializing CPU#1
> Calibrating delay using timer specific routine.. 4005.37 BogoMIPS
> (lpj=8010751)
Why do you think it cannot be a cache warming effect?
--
vda
[email protected] wrote:
>On Wednesday 21 September 2005 16:20, [email protected] wrote:
>
>
>>Hello,
>>
>>I noticed that the bogomips results for the two cores on my machine are
>>consistently not the same, the second one is always reported slightly
>>faster, it's a small difference and I saw the same in a posted dmesg
>>
>>
>from
>
>
>>somebody else on the list. Which made me wonder:
>>
>>
>
>I guess it's a cache warming effect. Please show the numbers.
>--
>vda
>
>Probably not, got this one from a web site, and on this one the first core
>seems to be faster (can't check my own machine it's off and at home and
>I'm at work.) The difference I get is similar, but always with the second
>one faster. It's the same when using cat on /proc/cpuinfo. Oh and I saw it
>on 2.6.11 and 2.6.12 as supplied with fedora core 4 myself.
>
>Calibrating delay using timer specific routine.. 4014.73 BogoMIPS
>(lpj=8029470)
>Mount-cache hash table entries: 512
>CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
>CPU: L2 Cache: 512K (64 bytes/line)
>CPU 0(2) -> Core 0
>Intel machine check architecture supported.
>Intel machine check reporting enabled on CPU#0.
>mtrr: v2.0 (20020519)
>Enabling fast FPU save and restore... done.
>Enabling unmasked SIMD FPU exception support... done.
>Checking 'hlt' instruction... OK.
>CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
>Booting processor 1/1 eip 2000
>Initializing CPU#1
>Calibrating delay using timer specific routine.. 4005.37 BogoMIPS
>(lpj=8010751)
>CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
>CPU: L2 Cache: 512K (64 bytes/line)
>CPU 1(2) -> Core 1
>Intel machine check architecture supported.
>Intel machine check reporting enabled on CPU#1.
>CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
>Total of 2 processors activated (8020.11 BogoMIPS).
>
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
opposite result here - 2nd one is faster (from /proc/cpuinfo):
processor : 0
vendor_id : AuthenticAMD
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
cpu MHz : 2211.337
bogomips : 4374.52
...
processor : 1
vendor_id : AuthenticAMD
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
cpu MHz : 2211.337
...
bogomips : 4407.29
> > I noticed that the bogomips results for the two cores on my machine
are
> > consistently not the same, the second one is always reported slightly
> > faster, it's a small difference and I saw the same in a posted dmesg
> from
> > somebody else on the list. Which made me wonder:
>
> I guess it's a cache warming effect. Please show the numbers.
>
> Probably not, got this one from a web site, and on this one the first
core
> seems to be faster (can't check my own machine it's off and at home and
> I'm at work.) The difference I get is similar, but always with the
second
> one faster. It's the same when using cat on /proc/cpuinfo. Oh and I saw
it
> on 2.6.11 and 2.6.12 as supplied with fedora core 4 myself.
>
> Calibrating delay using timer specific routine.. 4014.73 BogoMIPS
> (lpj=8029470)
...
> Initializing CPU#1
> Calibrating delay using timer specific routine.. 4005.37 BogoMIPS
> (lpj=8010751)
Why do you think it cannot be a cache warming effect?
--
vda
----------
Because with this one the first case was the faster one, that would need
cache cooling :)
But besides that, as far as I remember the actual loop is about 3
instructions long and will be cache hot in a time that you'd never notice
in the end result.
Sorry about the formatting, but it's lotus notes :/
Hi, Robert and Denis!
> > Why do you think it cannot be a cache warming effect?
> ----------
> Because with this one the first case was the faster one, that would need
> cache cooling :)
Well, can't we actually try to estimate the real temperatures of the caches
and adjust the BogoMIPS accordingly?
Usually, semiconductors tend to run faster when they are getting cooler?!
Sorry, couldn't resist... ;-)
Greets,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19