too few bogoMips on MPC8313E-RDB ?

8 messages, 6 authors, 2008-11-26 · open the first message on its own page

too few bogoMips on MPC8313E-RDB ?

From: Norbert van Bolhuis <hidden>
Date: 2008-11-26 10:03:30

This is what a linux-2.6.x reports (for the MPC8313E running at 333 MHz):
Calibrating delay loop... 83.20 BogoMIPS (lpj=166400)

Which can't be correct.

A MPC870 (running at 133 mhz) has ~ 131.07 BogoMIPS

Anyone know why it's only 83.20 ?

Of course it's only a benchmark figure. I don't know if
CPU performance is *really* lacking, I sure hope not.

Re: too few bogoMips on MPC8313E-RDB ?

From: Alessandro Rubini <hidden>
Date: 2008-11-26 10:33:31

This is what a linux-2.6.x reports (for the MPC8313E running at 333 MHz):
Calibrating delay loop... 83.20 BogoMIPS (lpj=166400)

Which can't be correct.

A MPC870 (running at 133 mhz) has ~ 131.07 BogoMIPS
Actaully, one-instruction-per-clock leads to BogoMIPS = MHz.

Your "loop per jiffies" value shows you make 332800 instructions per
jiffy (a loop is two instructions: increment and jump).

So most liker your timer tick runs at 1000 Hz but Linux is thinking
it's at 250Hz (332800 * 250 = 83.20 millions).
Of course it's only a benchmark figure.
No, it's not a benchmark figure. It's the metric by which udelay() is
calculated. So your udelays (and mdelays) will be 4 times shorter than
required, and some hardware may be misbehaving as a result.

Hope this help
/alessandro, who however is not runing a powerPC these times

Re: too few bogoMips on MPC8313E-RDB ?

From: Norbert van Bolhuis <hidden>
Date: 2008-11-26 14:33:02

Thanks for the answer, but that's not it.

I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK.

It must be something else, I still think 83.20 BogoMIPS
can't be correct for a MPC8313 running at 333 MHz.


Alessandro Rubini wrote:
quoted
This is what a linux-2.6.x reports (for the MPC8313E running at 333 MHz):
Calibrating delay loop... 83.20 BogoMIPS (lpj=166400)

Which can't be correct.

A MPC870 (running at 133 mhz) has ~ 131.07 BogoMIPS
Actaully, one-instruction-per-clock leads to BogoMIPS = MHz.

Your "loop per jiffies" value shows you make 332800 instructions per
jiffy (a loop is two instructions: increment and jump).

So most liker your timer tick runs at 1000 Hz but Linux is thinking
it's at 250Hz (332800 * 250 = 83.20 millions).
quoted
Of course it's only a benchmark figure.
No, it's not a benchmark figure. It's the metric by which udelay() is
calculated. So your udelays (and mdelays) will be 4 times shorter than
required, and some hardware may be misbehaving as a result.

Hope this help
/alessandro, who however is not runing a powerPC these times

Re: too few bogoMips on MPC8313E-RDB ?

From: Leon Woestenberg <hidden>
Date: 2008-11-26 14:37:45

Hello,

On Wed, Nov 26, 2008 at 3:20 PM, Norbert van Bolhuis
[off-list ref] wrote:
Thanks for the answer, but that's not it.

I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK.

It must be something else, I still think 83.20 BogoMIPS
can't be correct for a MPC8313 running at 333 MHz.
For an extra data point, I checked on my MPC8315E-RDB:

root@mpc8315e-rdb:~# cat /proc/cpuinfo
processor       : 0
cpu             : e300c3
clock           : 400.000002MHz
revision        : 2.0 (pvr 8085 0020)
bogomips        : 66.56
timebase        : 33333333
platform        : MPC831x RDB


I can check on a MPC8313E-RDB later.

Regards,
-- 
Leon

Re: too few bogoMips on MPC8313E-RDB ?

From: Geert Uytterhoeven <hidden>
Date: 2008-11-26 14:41:48

On Wed, 26 Nov 2008, Norbert van Bolhuis wrote:
Thanks for the answer, but that's not it.

I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK.

It must be something else, I still think 83.20 BogoMIPS
can't be correct for a MPC8313 running at 333 MHz.
On PPC, BogoMIPS depends on the decrementer frequency, not on the CPU clock.

Check `timebase' in /proc/cpuinfo, which is e.g. 79.8 MHz on a PS3 (while the
actual Cell processor runs at 3.2 GHz). That's why the PS3 gets only 159
BogoMIPS.
Alessandro Rubini wrote:
quoted
quoted
This is what a linux-2.6.x reports (for the MPC8313E running at 333 MHz):
Calibrating delay loop... 83.20 BogoMIPS (lpj=166400)

Which can't be correct.

A MPC870 (running at 133 mhz) has ~ 131.07 BogoMIPS
Actaully, one-instruction-per-clock leads to BogoMIPS = MHz.

Your "loop per jiffies" value shows you make 332800 instructions per
jiffy (a loop is two instructions: increment and jump).

So most liker your timer tick runs at 1000 Hz but Linux is thinking
it's at 250Hz (332800 * 250 = 83.20 millions).
quoted
Of course it's only a benchmark figure.
No, it's not a benchmark figure. It's the metric by which udelay() is
calculated. So your udelays (and mdelays) will be 4 times shorter than
required, and some hardware may be misbehaving as a result.

Hope this help
/alessandro, who however is not runing a powerPC these times
With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: too few bogoMips on MPC8313E-RDB ?

From: Dominik Bozek <hidden>
Date: 2008-11-26 14:54:05

Norbert van Bolhuis wrote:
Thanks for the answer, but that's not it.

I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250)
is OK.

It must be something else, I still think 83.20 BogoMIPS
can't be correct for a MPC8313 running at 333 MHz.


Alessandro Rubini wrote:
quoted
quoted
This is what a linux-2.6.x reports (for the MPC8313E running at 333
MHz):
Calibrating delay loop... 83.20 BogoMIPS (lpj=166400)

I never been worried for the BogoMIPS, but actually my board (custom
one) report:
Calibrating delay loop... 66.56 BogoMIPS (lpj=133120)
The core is running at 333MHz also, but what make my focus is the result
of calibrating: 66.56. The main oscillator on my board is 66MHz!? Is the
main oscillator on your board 83.3MHz?
BTW. I'm using older kernel 2.6.20 with patches from freescale.

Regards

Re: too few bogoMips on MPC8313E-RDB ?

From: Norbert van Bolhuis <hidden>
Date: 2008-11-26 16:09:39

ok, so it depends on the decrementer frequency
(which is 41666666 on my system).

Btw. the main oscillator on my board is not 83.3 mhz,
it's 66 mhz as well.

Hmmm. so by using the decrementer for the clock tick/irqs
(which perfectly makes sense) the bogoMIPS value is
nonsense now. That's a pity, but at least now I know/understand.

Thanks to everybody for their answers.

Re: too few bogoMips on MPC8313E-RDB ?

From: Gabriel Paubert <hidden>
Date: 2008-11-26 17:05:47

On Wed, Nov 26, 2008 at 05:09:39PM +0100, Norbert van Bolhuis wrote:
ok, so it depends on the decrementer frequency
(which is 41666666 on my system).

Btw. the main oscillator on my board is not 83.3 mhz,
it's 66 mhz as well.
66MHz is the crystal frequency, but then clock generators
use PLL to generate about anything from it. Actually people
use the abomination called DFS (frequency spreading) to comply
with requirements on radiated energy; that's a bad joke, it does
not actually reduce radiated energy, but spreads it over wider
bandwidth which makes it much harder to detect with standard
test equipement.
Hmmm. so by using the decrementer for the clock tick/irqs
(which perfectly makes sense) the bogoMIPS value is
nonsense now. That's a pity, but at least now I know/understand.
As far as I know, there are other architecture on which it is
as bogus. Besides that it has the advantage of being really constant
even when CPU frequency changes.

	Regards,
	Gabriel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help