Overclocking

[dom]

I've not tested extensively but tried the following tests, which all show the same performance levels:

1. core_freq=500
2. core_freq=500 and gpu_freq=250
3. default
4. core_freq=500 and avoid_pwm_pll=1
5. gpu_freq=500 and avoid_pwm_pll=1

Thanks for the bug report. You are quite right. I've pushed out a fix.

@dom
@shalo
I built a spreadsheet to show the valid integer divisors of core_freq. Shows product and true or false for integer.
What I would like to know; one half and one third are valid divisors, are 2/5 and 3/5 valid?
instance: (3/5)
core_freq=500
gpu_freq=300
or
h264_freq=300
isp_freq=300
v3d_freq=300
Thank you!

@dom
@shalo
I built a spreadsheet to show the valid integer divisors of core_freq. Shows product and true or false for integer.
What I would like to know; one half and one third are valid divisors, are 2/5 and 3/5 valid?
instance: (3/5)
core_freq=500
gpu_freq=300
or
h264_freq=300
isp_freq=300
v3d_freq=300
Thank you!

Well, you can use any combination of core_freq and gpu_freq if you also use avoid_pwm_pll=1. The lasting side effect to this seems to be a slight hiss when using analogue audio (Works now in the few minutes old update, though I have switched to hdmi audio and didn't test the audio too much).

Without using avoid_pwm_pll=1 that example it would not be valid:
500 core = 1000pll and 1000/300=3.333. there's not really a lot you can do with that pll practically. 200, 250, 500 are the only gpu_freq of note and 500 too high, 200 too low (though is valid at 2/5ths.

At quadruple PLL values you could use 4/5 since that fits nicely into 4, 5 times. Soooo to test 290 core (x4 - 1160 pll) with 4/5 value for gpu would be 232mhz. 1160 PLL and 1160/232=5.

Sooo 4/5s will be possible for some values where core is lower than 300mhz (300/240 is valid if 300 is 1200 pll and not 600pll).

Practically though I think if you are not using avoid_pwm_pll you will either use 1:1, 1:2, 2:3 or maybe 1:3 in some extreme cases.

I think a formula along these lines will help you out. For a given PLL value the divisor itself has to be an integer of the PLL multiple. So for PLL=2xCORE then 2 can be divided by 1, 2/3, 1/2, 1/3 and where PLL=4xCore those all hold true but 4 can also be divided by 4/5 so that becomes valid, not sure if anything else of interest becomes valid, it's late

Yep that was a bad example. I guess I should have put it into the spreadsheet I wasted my time making! It was not an integer divisor. As long as it is an integer divisor it should work then;
Some examples from the spreadsheet. One Half of pll is always going to be a valid number.
If core_freq=323 so would be an integer of:
1/4=161.g not valid (false)
1/3=215.33 not valid
1/2=323 valid (true)
2/5=258.4 not valid
3/5=387.6 not valid

If core_freq=400 so would be an integer of:
1/4=200 valid
1/3=266.5 not valid
1/2=400 valid
2/5=320 valid
3/5=480 valid, but probably not useful

If core_freq=450 so would be an integer of:
1/4=225 valid
1/3=300 valid
1/2=450 valid
2/5=360 valid
3/5=540 valid, but probably not useful

Yep that was a bad example. I guess I should have put it into the spreadsheet I wasted my time making! It was not an integer divisor. As long as it is an integer divisor it should work then;
Some examples from the spreadsheet. One Half of pll is always going to be a valid number.
If core_freq=323 so would be an integer of:
1/4=161.g not valid (false)
1/3=215.33 not valid
1/2=323 valid (true)
2/5=258.4 not valid
3/5=387.6 not valid

If core_freq=400 so would be an integer of:
1/4=200 valid
1/3=266.5 not valid
1/2=400 valid
2/5=320 valid
3/5=480 valid, but probably not useful

If core_freq=450 so would be an integer of:
1/4=225 valid
1/3=300 valid
1/2=450 valid
2/5=360 valid
3/5=540 valid, but probably not useful

Uh, you've changed your fractions in this. Before you had 500 core and 300 gpu meaning 3/5 fraction. In all these situations above these fractions would be double what they were in the previous example. so 2/5 is really 4/5 and gpu as 4/5 of core are only valid when the PLL is equal to quadruple Core (eg core below ~301).

None of those 2/5 entries will be valid if we say as before that gpu is 4/5 of the core.

As an example from final group. That ought to be 360/450 = 4/5 and invalid since 450x2=900 and 900/360=2.5

Edit: If you are changing the fraction to be of the PLL value it is much simpler. All your fractions will need to be integer divisors of 1. So only 1, 1/2, 1/3, 1/4, 1/5, 1/6 and so on.

@shalo:
All the outputs were derived from pll.
core_freq is the input = 450
pll = 900
1/2 of pll = 450
1/3 of pll = 300
1/4 of pll = 225
etc.
true (valid) or false (false) is determined by a decimal being present.
After reading your edit I will change the spreadsheet accordingly. The question is then what would be the lowest (usable) divisor. 1/6?
now reflects:
core_freq = 450
pll = 900
1/2 pll = 450
1/3 pll = 300
1/4 pll = 225
1/5 pll = 180
1/6 pll = 150
I must have missed a discussion here someplace about core below ~ 301 and quadruple though I think that is tied to the pll above 600, just do not remember a pll as quadruple. I will have to go back through the post to see where that is. I am trying to build a table of "valid" overclock settings. Not that they will work with every RasPi, just what would be valid settings that avoid the mixed timing.

ive been running my pie at 1120 it is fast and stable doesnt seem to get any hotter than normal.

After reading your edit I will change the spreadsheet accordingly. The question is then what would be the lowest (usable) divisor. 1/6?

Hard to say, the gpu downlocks/powersaves on its own apparently, so there's no real mileage from that point of view. It seems to me that there is little point choosing any divisor if there is another that is closer to 250 without going over. Personally, I'm happy on my board to keep gpu at 250 and core at 500+ now. Things may change when we see Android/accelerated X etc...

I must have missed a discussion here someplace about core below ~ 301 and quadruple though I think that is tied to the pll above 600, just do not remember a pll as quadruple. I will have to go back through the post to see where that is. I am trying to build a table of "valid" overclock settings. Not that they will work with every RasPi, just what would be valid settings that avoid the mixed timing.

That comes from the way I read the formula provided by dom:
pll_freq = core_freq * 2^n, for smallest n satisfying pll_freq > 600MHz.

so for 601+ core you'd have what pll = 601 * 2^0 = 601 PLL

Then 300 (or lower core) you'd have pll = 300 *2^2 = 1200 PLL

Everything inbetween those two values would be pll = core x 2^1 or pll = core x 2

I'm thinking about overclocking mine to 800 MHz, will that have much of a reduction on the life of my Pi?

[dom]

I'm thinking about overclocking mine to 800 MHz, will that have much of a reduction on the life of my Pi?

No.
If you had said you were overvolting to 1.4V and overclocking to 1200MHz, the answer would be probably not.

These were my best setting:
over_voltage=6
arm_freq=1000
core_freq=500
sdram_freq=500

Running raspbian with those settings, and desktop/midori was pretty responsive.

using these settings for several hours, no problems with stability.

I didn't quite got the idea about divider/divisor. How do you configure it in /boot/config.txt
If I set core_freq=350mhz - which divisor will be used for the rest of gpu components?

I didn't quite got the idea about divider/divisor. How do you configure it in /boot/config.txt
If I set core_freq=350mhz - which divisor will be used for the rest of gpu components?

That's not quite the right question. If you set core_freq=350mhz then the core will run at 350mhz. Everything else will be at default settings.

But to explain further that specific example it would affect other settings as follows:

Because you have set 350mhz core frequency, the pi would set up a PLL at 700mhz. This is quite straight forward here. This tells you a sort of "master timing" of 700 and your core set at 350 has no problem with this, it can effectively skip every other signal. This will always make sense since the PLL is always derived from the core in the first case, they will always be "compatible" and you'll always be able to derive the core from the PLL.

Since you have not changed any other settings, the 3D/H264 will run at the default speed of 250mhz. The issues occur because how is it going to generate 250mhz for say the 3D block given that it needs to derive this from a 700mhz source? It can't just take every nth signal because 700/250 is not an integer.

What would actually happen is that the 3D block would run at 250mhz (default) on average as you have asked it to but it would get there by a mixture of 350mhz (43%) and 175mhz (57%) which is probably not ideal.

If you had set the core to 375mhz, then the PLL would have been 750mhz and then it could generate a "clean" 250mhz for the 3D block since 750/250=3.

I hope understand now. It good practice to check if core x 2 freq can be divided with integer to get freq of 3d/h264/etc.
So properly overclocking algo looks like this
find stable core_freq
step up rest of components to core_freq*2/integer freq
continue until it still works.
And if you don't touch 3d/h264 freqs next step from 375 should be 500 - which can be too much.
Thanks for explanation!

I hope understand now. It good practice to check if core x 2 freq can be divided with integer to get freq of 3d/h264/etc.
So properly overclocking algo looks like this
find stable core_freq
step up rest of components to core_freq*2/integer freq
continue until it still works.
And if you don't touch 3d/h264 freqs next step from 375 should be 500 - which can be too much.
Thanks for explanation!

You've pretty much got it yes.

Also there is a config option with newer firmware avoid_pwm_pll=1 which removes the relationship by using another PLL. With that set, core_freq has no relationship with 3d/h264 (though these need to be the same) but there may be a very slight cost in audio quality from the analogue output.

My has been rocking along, nice and stable.

arm_freq=900
sdram_freq=450
gpu_freq=325
core_freq=325
h264_freq=325
isp_freq=325
v3d_freq=325

[dom]

My has been rocking along, nice and stable.

arm_freq=900
sdram_freq=450
gpu_freq=325
core_freq=325
h264_freq=325
isp_freq=325
v3d_freq=325

gpu_freq means core_freq+h264_freq+isp_freq+v3d_freq. So:
arm_freq=900
sdram_freq=450
gpu_freq=325

is all you need.

Hey guys, i already get my pi @germany yesterday

It is so cute

A Question, i want to overclock a bit and just to be on the safe side i want to use headpipes, which are especially for the pi ? can anyone give me a recommandation?

Greetz and thx in advance

Multisaft7

Hi,

The short version:
Anyone have a way of measuring the effects of raising sdram_freq?

The longer version:
I've been trying to find the best stable settings for my pi. So far I've been using "time echo "scale=XXXX;4*a(1)" | bc -l" to count pi desimal places and measure progress with every step (XXXX being 1000, 2000, 3000, 5000 and 10000). It seems I've received a pretty good CPU since 960 seems to be the best stable frequency without overvolting. 960 would seem to be giving roughly 31-32% improvement in CPU intensive tasks compared to stock values.

The thing is I've begin finding the best setting for sdram_freq but I have no reliable way of measuring the effects. With sdram_freq 450 I still saw some improvement in the test above but sdram_freq 500 is already lowering my test scores. Not much but enough to be measurable. That leaves me wondering if its still beneficial to use sdram_freq 500 or even above. Is there a simple way of measuring it?

Hi,
The short version:
Anyone have a way of measuring the effects of raising sdram_freq?

Yes, I use membench. https://github.com/ssvb/ssvb-membench

I've pulled out four columns that show roughly the difference. The fourth in red is actually a different pi with Hynix ram that doesn't easily do whatever the maximum is (it's slightly below 600mhz I believe). At any rate, you can see how much core frequency affects memory bandwidth/latency compared to ram speed.

Nice data there @shalo.
I have a RasPi with the Hynix memory and it does not overclock well at all. Stability problems. The SoC isn't much better. I only made it to 950 with an overvolt of 8 and it still was not stable. It runs ok at 900 with an overvolt of 6. I am running it now at 800 with no overvolt. It is my test dummy since it does not want to cooperate.

Its beatings will continue until Morale,,,, I mean, its Overclock improves!

Nice data there @shalo.
I have a RasPi with the Hynix memory and it does not overclock well at all. Stability problems. The SoC isn't much better. I only made it to 950 with an overvolt of 8 and it still was not stable. It runs ok at 900 with an overvolt of 6. I am running it now at 800 with no overvolt. It is my test dummy since it does not want to cooperate.

Its beatings will continue until Morale,,,, I mean, its Overclock improves!

There seems to be something in the SD card used. I thought when testing I would just use sd card for simplicity's sake but saw very quick corruption to SD card data above 900mhz. When using a USB flash drive for the operating system, I benched 1100mhz with 6 overvolt. 1150 was too much but didn't corrupt any data.

The other thing I've found is that neither of my rpis like the gpu overclocked much. Maybe 255mhz for quake3, maybe. But 260mhz and it doesn't like it within about 3mins. When I was testing (not 3d), the core was ok at 550 but as I was using 275 for gpu I didn't pursue it. I'm surprised some people can use 350 gpu with no overvoltage and presumably it be stable in quake3...

Hi,
The short version:
Anyone have a way of measuring the effects of raising sdram_freq?

Yes, I use membench. https://github.com/ssvb/ssvb-membench

First time I compiled anything, ever, but to my amazement it's actually working.
Might have to start compiling more programs before my luck runs out. Thanks!

@shalo:
All three of my RasPii tolerate gpu_freq=320, and so does my brothers RasPi. The GPU seems to be the least tolerant to overclocking of all the settings. I did not run into any SD corruptions issues, but I tested them all on my Lapdock that uses a USB HDD. That Lapdock setup is the most useful tool for working on RasPii! The other two RasPii I have not tried any overvolt on as yet. Both of them run 850 to 900 with no overvolt plus GPU at 320 and memory at 500 and are stable.

I really have not tried much with core_freq yet. Been busy working out the WiFi on Lapdock, just setup a RasPi as a web server and playing with OpeElecXBMC on RasPi #1

RasPi #1 with the Hynix memory is the one I have been back-powering from a USB hub. Around a month of use like this and it is running fine. But when I need to try some soldering on a RasPi it is the candidate.

pi@raspberrypi ~ $ cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 1099.36
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 1000002
Serial : 00000000bb3ca***

config file:
arm_freq=1100
core_freq=500
sdram_freq=550
over_voltage=8
over_voltage_sdram=1


5000 numbers benchmark:
real 2m39.566s
user 2m39.290s
sys 0m0.010s

2000 numbers benchmark:
real 0m15.436s
user 0m15.400s
sys 0m0.010s

running stable for 2 days now with small heatsinks attached to lan-chip (directly behind usb and audiojack) and processor.
heat sinks: cpu: http://www.conrad.de/ce/de/product/1879 ... Detail=005
lan: http://www.conrad.de/ce/de/product/1879 ... Detail=005
thermalpaste: http://www.conrad.de/ce/de/product/1890 ... AREA_27808

some hint for the lazy guys:
type cd ~
nano .bashrc
and add the following commands:
alias benchme='time echo "scale=2000;4*a(1)" | bc -l'
alias benchmehard='time echo "scale=5000;4*a(1)" | bc -l'

after you logoff and login again with the current user you used to add those commands you will be getting benchme for the 2000numbers and benchmehard for 5000

sincerely,

acid