News How to Overclock Any Raspberry Pi

Toggle sidebar Toggle sidebar
Status
Not open for further replies.
A few practical tips though.

Thanks to silicon lottery, your particular unit may not overclock proportionally the gpu and the cpu part the same as well. So, if you don't need faster graphics, don't overclock its GPU. This increases your chance to overclock higher and have a stable system. Also lower power consumption and less supply current means better stability.

Raspberry Pis with 4 CPU cores may hit a power delivery wall when loaded with all 4 cores active. The integrated PMIC (power management IC) may not supply the needed current for all of the cores, and turn itself off for a short period of time, thus rebooting the Pi. Cool the PMIC too.

Don't overvolt at max if you need all-core load (kernel compiles, heavy number crunching etc). Here we have a RPI4 which can run at 1850MHz with all cores active with over_voltage=2, but with higher over_voltage=3, it reboots when loaded. Higher over_voltage means also higher current and the PMIC circuitry has limited output current. The hotter the PMIC and its surrounding inductors, the less current it can supply. This is a limitation of the PMIC chip, not the BCM chipset.

So, if you encounter occasional reboots under heavy load, it may be the overheating of the PMIC. If your Pi locks up, it won't be this particular problem, but perhaps silicon lottery loss.

Underclocking a GPU part may be an interesting way of increasing overclockability (more stable system), but AFAIK, older Raspberry Pis had L2 cache tied to the GPU, so underclocking it may slow the CPU too.

I've documented how the PMIC of Raspberry Pi 4 heats - all other chips being cooled directly to a heatsink. The view is from an underside, i.e. you see the heated PCB . Lower left corner is the PMIC.
 
Was so glad when I found a RPi overclocking tutorial here at Tom's, a site I trust to get it right.

There are all kinds of tutorials out there but none of them I've come across anyway, mentioned the core_freq and sdram_freq.

I have two RPi4 - 4Gbs. The first I got to 2147, but after about an hour it would finally crash. I just dropped it to 2140 and it's rock solid; been surfing and working in terminal all day with like 10+ tabs open in Chromium. No problems.

For anyone who finds those numbers impressive (I do!), keep in mind, I am using Ice Tower Fan/Heatsink Coolers on both units. One is mounted to the top surface of an Argon Neo aluminum case, and the other is just using the included Ice Tower 'case', which I don't really consider a case, as it doesn't protect the inner hardware from physical damage in any way. I'm looking at my sensor readings right now, and they have yet to go above 34 degrees celcius even at full load. Wow!!

I didn't get as lucky in the silicon lottery with the second RPi4. After MANY adjustments, it settled in at 2070. But again, absolutely rock solid. I do not feel any noticeable performance difference between 2.07 and 2.14 Ghz.

The main benefits I'm seeing with the OC's are:

Web browsing is now nearly as good as my 8th Gen i5 laptop - impressive!! No more hesitating when scrolling, everything is smooth as buttah. I think force_turbo=1 is what is making that such a better experience.

Video: with the latest update to RaspberryPi OS 64-Bit, you can now enable fake GL drivers and Compositor, and YouTube performance is greatly improved. (I tried every combination, this is the best one) There is still occasional tearing, but MUCH MUCH less. It's perfectly acceptable. Also, hardly any dropped frames, and 90% of those seem to always happen in the first 15 seconds of the video. I ran Big Buck Bunny at 1080p/60fps and only had 11 dropped frames throughout the entire video. Again, impressive.

As soon as I finish this post (Rpi Zero is finishing rpi-update) I am going to OC the Zero W and see how far I can get that to go.

Here are my OC settings for 2140, pretty much the same as you suggest:

[pi4}
arm_freq=2140
over_voltage=6
gpu_freq=750
core_freq=500
sdram_freq=500
force_turbo=1

(and no, my warranty didn't void, if anyone is curious)

Keep up the good work!
-T
 
Todd Melanson said:
Here are my OC settings for 2140, pretty much the same as you suggest:

[pi4}
arm_freq=2140
over_voltage=6
gpu_freq=750
core_freq=500
sdram_freq=500
force_turbo=1

(and no, my warranty didn't void, if anyone is curious)

Keep up the good work!
-T
Click to expand...

With stable firmwares, you don't overclock GPU with the core_freq keyword. Only experimental/unstable firmwares do that. Instead of it, you can use hdmi_enable_4kp60=1 to overclock from 500 to 550MHz (Videocore GPU). You lose composite video output though, because it reguires cca 360MHz core clock.

force_turbo without overvolting above 6 doesn't void warranty. You can force turbo by using performance governor. Just FYI.

Try this (with root privileges on Ubuntu et all not raspbian) :

for src in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi ; do echo -e "$src:\t$(vcgencmd measure_clock $src)" ; done

Here's mine output without the hdmi_enable_4kp60=1 setting:
arm: frequency(48)=2000531200
core: frequency(1)=500000992
h264: frequency(28)=0
isp: frequency(45)=0
v3d: frequency(46)=500000992
uart: frequency(22)=48001464
pwm: frequency(25)=107143064
emmc: frequency(50)=250000496
pixel: frequency(29)=150002928
vec: frequency(10)=0
hdmi: frequency(0)=0
dpi: frequency(4)=0

And with it:

arm: frequency(48)=2000478464
core: frequency(1)=550006336
h264: frequency(28)=0
isp: frequency(45)=0
v3d: frequency(46)=500000992
uart: frequency(22)=48001464
pwm: frequency(25)=107143064
emmc: frequency(50)=250000496
pixel: frequency(29)=150042480
vec: frequency(10)=0
hdmi: frequency(0)=0
dpi: frequency(4)=0

I've just noticed, that if I don't run X window system, the core frequency is locked to arm frequency somewhat or is fluctuating. Definitely it thinks it doesn't need all the power and downclocks the core. More elaboration on this would be required.

Last but not least, to change the scaling governor, use a command:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
with root rights (start a root shell by sudo bash for example...)
There are other scaling governors (ondemand, powersave). List them with:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

my system shows:
conservative ondemand userspace powersave performance schedutil


This setup is for 4GB model of RPI4, but works the same on 8GB model I also have.
 
Last edited:
Todd Melanson said:
I have two RPi4 - 4Gbs. The first I got to 2147, but after about an hour it would finally crash.
Click to expand...

Just an addendum, there are two types of crashes. One is a freeze, i.e. it stops responding. The other one is reboot - and that's caused by overload of its power management chip, which can't supply enough current at the preset voltage AND temperature. In other words, if it overheats, its maximum current output drops and when the BCM chip needs more, it reboots. The voltage at the 1V rail drops for a short while.

CooliPi has thermal bridge between the PMIC and a heatssink itself. We've tested soft thermal pads, and it works well.
 
MiauCat said:
I have built a web-based overclocking tool for several Raspberry Pi models, including Pi 4 and Pi 400. It suggests medium and maximum overclocking settings to you, as a good starting point - to take the guesswork out of the initial step!

Possibly you'll find it useful:

https://picockpit.com/raspberry-pi/overclock-raspberry-pi/




I'm also including information about how to test whether an overclock is stable on the tool's page.
Click to expand...

Cool, I've tested it. But I can go even further - my settings are these (8GB version):

arm_freq=2350
gpu_freq=750
over_voltage=10
force_turbo=1
hdmi_enable_4kp60=1

The September 2020 update of mainline firmware enables this. It's rock solid, at 2400MHz it sometimes locks after boot (but in desktop) even with higher over_voltage. I use CooliPi 4B, of course ;-) - so that's passive.

I was wrong in one of my previous posts about arm, gpu and core frequncy dependency - they're all independent. It was based on some comments of Eben Upton some time ago when information was scarce.

core frequency (includes L2 cache) can be increased by hdmi_enable_4kp60=1 from 500MHz to 550MHz, but you loose composite video output.

So, you can upgrade your online tool to max out the frequencies - not just ARM CPU, but for the core and gpu too. And max stable frequency in my case is 2350MHz, maybe higher towards 2400MHz. I have yet to test it in a fridge at 2400MHz with CooliPi.

You can also warn users of 1/2/4GB versions of Raspberry Pi 4 about stability - its PMIC can't supply anough juice for all of the cores at max. 8GB version is fine, upgraded PMIC with 50% higher switching frequency. I reach max temperatures of about 48˚C with passive cooling with approximately 23˚C ambient temperature - max load.
 
Thank you for having a look at my overclocking tool :)

"I was wrong in one of my previous posts about arm, gpu and core frequncy dependency - they're all independent. It was based on some comments of Eben Upton some time ago when information was scarce. "

I think I've read something about one of the dynamic clocks not being available anymore due to dynamic frequency scaling for the Pi 4 in a recent Firmware - and thus the GPU clock not being able to set independently? That should still be accurate, or what were you thinking about?

Interesting stuff about the PMIC, as well! I knew that it was upgraded to be able to handle the additional RAM - but actually yet another reason to go with the 8 GB model, for people serious about the Raspberry Pi.

I think probably the best idea for me would be to distinguish between Pi 4 (1 / 2 / 4 GB) and Pi 4 (8 GB), what do you think?

May I add your settings as "maximum performance" for this?
arm_freq=2350
gpu_freq=750
over_voltage=10
force_turbo=1
hdmi_enable_4kp60=1

Also, I've just sent you a mail over on https://www.coolipi.com/Contact.html for some other off-topic questions

Cheers,
Max
 
This seems all well and good but it leaves a few unanswered questions.
1. What do we do with the setting already available in config.txt which says to uncomment to overclock the arm. It indicates that 700 MHz is the default, and the overclock freq seemingly suggested here is 800 MHz. It seems shocking therefore to see you indicating we should set it to 2200 MHz!
2. Does the "run as fast as firmware / board allows" setting "arm_boost=1" really do what it says? If so, why is that not sufficient?
3. The built-in "suggested" overclock to 800 doesn't say anything about increasing the voltage, and I don't remember what the voltage needs to be for various levels of overclock.
4. Finally, increasing the voltage spec here doesn't mean that the power source is necessarily going to be able to provide that power, right? I'm currently powering my RPi from a powered USB dock which I'm surprised has been working fine, as it's also powering other USB devices, but at some point it's going to run out of steam and not be able to give what is being asked of it.

So yes of course we can experiment with these things and see what happens, but for me at least I'd like to know before using a different set of overclock parameters, why the set of parameters we've been given out of the box should not be used.
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom