Determining how fast your Pi really is

[Burngate]

http://www-mtl.mit.edu/researchgroups/M ... Thesis.pdf

Brilliant! Saved for bedtime reading.
Makes a lot of sense: to have one as a production check, since it wouldn't take up much room, and to divide it down to get a sensible answer.
I wonder if the other two (and maybe this one) came as part of different lumps of silicon, e.g. the Vc and the ARM. There wouldn't be much gained by removing them when the lumps were combined into one large wafer.

Thankyou, all.

Now to find a use for it.

[MaxK1]

Seeding a random number generator comes to mind...

[dom]

Seeding a random number generator comes to mind...

We do have a hardware block that generates random numbers...
http://www.raspberrypi.org/forums/viewt ... 75#p273944

[drgeoff]

The low single-digit MHz is probably because the "ring" is running at several hundred MHz and has an output divider to get a reasonable system cycle count per oscillator period.

Or just many gates in the ring?

[MaxK1]

I was aware of it, but I "misplaced" the reference to it. Thanks! Anyway, there are people who deal with random numbers that always seem to need something more/else/different. They used to drive me nuts. (That's my story and I'm sticking to it )

[Burngate]

The low single-digit MHz is probably because the "ring" is running at several hundred MHz and has an output divider to get a reasonable system cycle count per oscillator period.

Or just many gates in the ring?

If the delay in one gate is of the order of a ps (which it aught to be, in silicon capable of ~GHz) how many gates would be needed to bring it down to MHz, versus how many in a three-gate-loop and divider chain?

[Gert van Loo]

In total the chips has eight ring oscillators.
Two are in the PAD ring, one is in the centre.
The PADS ones are accessed as 0,1 the centre one as 2.

The other five are spread around and at least each block which can be powered on/off has one.
They are always placed where we expect the maximum voltage drop and as such represent the worse case.
These other five require different SW to enable and read them

The gates which make up the rings are not the standard silicon cells.
These are specially designed as a sort of delay cell and they use N-Mos and P-Mos structures as "equal" as possible.
This is so the process parameters of the N and P silicon is equally represented in the final speed.

[drgeoff]

The low single-digit MHz is probably because the "ring" is running at several hundred MHz and has an output divider to get a reasonable system cycle count per oscillator period.

Or just many gates in the ring?

If the delay in one gate is of the order of a ps (which it aught to be, in silicon capable of ~GHz) how many gates would be needed to bring it down to MHz, versus how many in a three-gate-loop and divider chain?

I think your picosecond is a bit optimistic* but I take your point. Three gates is probably not the sweet spot though. Add another two or four and the frequency drops to 3/5 or 3/7. Is 4 gates enough to make a divide by 2?

(* if the logic is clocked, at 1 GHz there is 1 nanosecond for things to settle before the next clock. I'm not arguing the gates in the Broadcomm chip are that slow, just not convinced they are of the order of 1000 times faster than that. )

[shalo]

Seeing posts that are just the one value which doesn't help with data collection. I included the 1.4v value though since that's what I used for the overclock.

256mb Model B (Samsung Ram)
3.002Mhz @ 1.2v
3.880Mz @ 1.4v
Arm: 1100mhz Core: 600mhz Ram: 600mhz over_voltage: 1.4v (Headless stress tested for 18hrs)

Notes:
1150mhz ARM boots but doesn't complete all of my benchmarks. Soft fail though and PI is still responsive. 1125mhz ARM completes my benchmarks but fails stress test, hardlocking. 625mhz Core completes most of the benchmarks but failed during larger memory tests and hard locks.

With Samsung ram 600mhz was a given with early boards. Hynix ram pretty much required increasing the voltage, so might be worth noting between the two in results or ignoring ram all together. I'd dare say though this is an issue with automatic "turbo" settings. I think 440-450mhz was about right for my Hynix board with out increased voltage.

Was the cap on ram ever established? I haven't tried any higher numbers and from what I recall the cap might have been actually slightly under 600?

[Burngate]

My brain must have inserted three extra zeros, just like my bike chain sometimes slips three teeth. Sorry, and thanks for the correction.

[milhouse]

512MB Model B - one of the first to be delivered after the 512MB upgrade.

The value from read_ring_osc seems to vary.

After booting:

Code: Select all

rpi512:~ # vcgencmd read_ring_osc
read_ring_osc(2)=3.041MHz (@1.20V)

and then a few minutes later:

Code: Select all

rpi512:~ # vcgencmd read_ring_osc
read_ring_osc(2)=3.054MHz (@1.20V)

Max stable overclock:

Code: Select all

arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=4
over_voltage_sdram=4

[Snailface]

Code: Select all

Model/Speed
A    read_ring_osc(2)=3.157MHz (@1.20V)
B(1) read_ring_osc(2)=2.935MHz (@1.20V)
B+   read_ring_osc(2)=2.865MHz (@1.20V)
B(2) read_ring_osc(2)=2.754MHz (@1.20V)

Turns out my fastest system is the one I use the least. Just my luck.

[shalo]

Code: Select all

Model/Speed
A    read_ring_osc(2)=3.157MHz (@1.20V)
B(1) read_ring_osc(2)=2.935MHz (@1.20V)
B+   read_ring_osc(2)=2.865MHz (@1.20V)
B(2) read_ring_osc(2)=2.754MHz (@1.20V)

Turns out my fastest system is the one I use the least. Just my luck.

This would be useful with the overclock info.

[hojnikb]

Code: Select all

Model/Speed
A    read_ring_osc(2)=3.157MHz (@1.20V)
B(1) read_ring_osc(2)=2.935MHz (@1.20V)
B+   read_ring_osc(2)=2.865MHz (@1.20V)
B(2) read_ring_osc(2)=2.754MHz (@1.20V)

Turns out my fastest system is the one I use the least. Just my luck.

Set overvoltage to 8 and overclock that baby. Should hit 1250Mhz+ easily.

Also... Is the hardcap of 1500Mhz still present in the firmware or is it higher nowdays ?
I've seen some folks voltmodding and upping the core voltage way beyond 1.4V

[zardoz99]

Rev 0010

[root@pidora ~]# vcgencmd read_ring_osc
read_ring_osc(2)=2.934MHz (@1.20V)

[shalo]

Rev 0010

[root@pidora ~]# vcgencmd read_ring_osc
read_ring_osc(2)=2.934MHz (@1.20V)

This is not helpful without the overclock info

[jamesh]

Rev 0010

[root@pidora ~]# vcgencmd read_ring_osc
read_ring_osc(2)=2.934MHz (@1.20V)

This is not helpful without the overclock info

What do you mean? Overclocking doesn't make any difference to the reported ring oscillator speed. Or do you want to know how fast the device could be overclocked?

[milhouse]

Or do you want to know how fast the device could be overclocked?

As per dom:

I'd be intested if overclockers can post their ring oscillator value (at 1.2V), and the highest stable overclock settings, and we'll see what the pattern is.

How else will you determine if there is any correlation between ring oscillator and maximum stable overclock, if you're only getting half the information?

[zardoz99]

Or do you want to know how fast the device could be overclocked?

As per dom:

I'd be intested if overclockers can post their ring oscillator value (at 1.2V), and the highest stable overclock settings, and we'll see what the pattern is.

How else will you determine if there is any correlation between ring oscillator and maximum stable overclock, if you're only getting half the information?

After taking that reading, I over-clocked to 1GHz using the following.
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6

This, as expected, made no significant difference to the resulting value.

[root@pidora ~]# vcgencmd read_ring_osc
read_ring_osc(2)=2.941MHz (@1.20V)
[root@pidora ~]#

I'm curious why the "over_voltage=6" didn't reflect in the output...

Update: I figured out why.. The "powersave" governor was in operation. Switching to "ondemand" gives this.. "read_ring_osc(2)=3.568MHz (@1.35V)".

I am not yet prepared to start stressing my brand new B+ until it breaks just to respond to a survey.
It's just as interesting to see what the spread of speeds are from the factory.

[jamesh]

You cannot damage the device by overclocking.

[milhouse]

over_voltage=6

This, as expected, made no significant difference to the resulting value.

[root@pidora ~]# vcgencmd read_ring_osc
read_ring_osc(2)=2.941MHz (@1.20V)
[root@pidora ~]#

I'm confused - is the abvoe read_ring_osc value when you have over_voltage=6? If so, your config isn't working and you are most likely not overclocked successfully. The current ARM voltage should be reflected in the read_ring_osc result - @1.20V is the stock over_voltage=0, @1.35V would be over_voltage=6.

Use "vcgencmd get_config int" to check your current frequency and voltage settings.

[zardoz99]

Updated my previous post regarding "over_voltage=6".

You cannot damage the device by overclocking.

What about over-volting? What are the absolute maximum tested values for all of the variables, with and without force_turbo enabled?

[shalo]

Updated my previous post regarding "over_voltage=6".

You cannot damage the device by overclocking.

What about over-volting? What are the absolute maximum tested values for all of the variables, with and without force_turbo enabled?

As I recall 6 is the maximum it allows without force_turbo. Using force_turbo will set your warranty bit if you have ANY over_voltage set at all. 8 is the maximum and that requires force_turbo otherwise it caps at 6. Is there any chance of that behaviour changing if the warranty bit has already been set?

Anyway, don't want to pressure anyone in to doing something they are uncomfortable with but the goal was to gather data with the hypothesis that there is a direct correlation between the osc value and overclocking potential.

While I don't think having an image pick up setting automatically is ever likely, it would be helpful to look at the chart and have an idea what your maximum overclock potential is as a starting point. If you are way off in testing, it might point to a power supply issue or some other factor and it would just be helpful. But of course a decent amount of data is needed first...and are we not just naturally curious?

[bryanandaimee]

For my old 256 meg model B

At 1.20V I get 3.004 MHz at 45 degrees core temp.
950 core is the best I get at 1.20V
and 1150 is marginally stable at 1.40V

RingOsc.jpg (25.88 KiB) Viewed 4679 times

Also from gathering a little data it looks like the ring oscillator frequency does change versus temperature. Also the frequency change per degree increases with increasing voltage. So for the overclockers around here, the higher the over_volt the more good your heat sink will do you. At 1.40V you get roughly 2% increase in frequency for a 30 degree decrease in temperature. Spreadsheet is included.

ring oscillator.zip

(3.34 KiB) Downloaded 152 times

If I get the time I'll test the two B+ I've got on order.

[gregeric]

New B+, vcgencmd read_ring_osc gives

3.086MHz @1.2V

Crude overclocking effort: raspi-config's default turbo mode, all OK at 1000MHz.

Manually editing /boot/config.txt, found stable limit at arm_freq=1150

That's with raspi-config's default turbo overclock settings unchanged ie
core_freq=500
sdram_freq=600
over_voltage=6

So I guess there is some further scope if I knew what I was doing!

A very useful improvement in performance is seen over stock: using Mathematica's image deconvolution as a test, the eagle was unblurred with Steepest Descent method, noise 0, iterations @ 5, in 89s with 700MHz clock. At 1150MHz, as well as a huge boost to loading time, the eagle was sharpened in just 51s