I would like the option to over clock my RPi 4. The latest firmware allows (from what I understand)over clocking up to 2000 MHz. Currently the options under “performance” doesnt allow this for RPi 4.
Thanks for your request. Jep that is needed.
You guys might run some tests, which combinations of arm_freq, core_freq and overvoltage lead to a stable system.
AFAIK sdram_freq has no effect on RPi4, it’s fix 3200. At least reading through some overclocking threads on the RPi forums it was never used, and checking it’s value (vcgencmd get_config sdram_freq) always returns zero.
I am currently running with:
Works wonders and is 100% rock stable after 6 hours of stress testing. It seems nearly all devices can hit that if the RPi4 is cooled actively. The RPi4 is a hot one, so DietPi should probably show a warning that active cooling is recommended, or the CPU will throttle easily.
People are reporting arm_freq=2000 is possible with over_voltage=4, but not all CPU can handle it (most can, but in the CPU-lottery you never know…). There is a risk the RPi won’t boot at those freqencies and require the user to manually edit the config.txt on a different system to restore the system.
My second RPi4 just arrived so I’m going to do some testing, and probably get a stable system at 2000 mhz. I’ll report back then.
Many thanks for sharing. 1600 should work without raising over_voltage I think? 2000 perhaps works with over_voltage=6 reliable (and sufficient cooling of course)?
I verified that 3200 sdram_freq is fixed on RPi4. There is only one 13XY (something like that) value that is available for failsafe testing, but nothing that is relevant for use.
core_freq can only be 500 (default) or 600.
So presets could be:
arm | core | voltage | name 1500 | 500 | 0 | (default) 1600 | 500 | 0 | (safe) 1600 | 600 | 2 | (medium GPU) 1750 | 500 | 2 | (medium ARM) 1800 | 600 | ? | (max GPU) 2000 | 500 | ? | (max ARM)
So one can choose to speed up either GPU-loading or ARM-loading tasks a bid more. Sets that run stable with over_voltage=6 should be the maximum, since AFAIK a higher values still voids guarantee and requires force_turbo=1.
Greetings MichaIng !
I have successfully overclocked two RPi4:s with the following settings (and both running stable with this fan shim).
Nice, thanks again for sharing. Okay so 2000/500 seems to work with over_voltage=4 at least in most cases. However, I will go through the raspberrypi.org forum before adding this, probably we use over_voltage=5 to be failsafe?
Probably we could even go higher clocks with over_voltage=6 .
Yes, I think I was just lucky. I don’t think 2000 mhz with over_voltage=4 should be general. From what I see on different forums a higher over_voltage is needed in some cases for being able to run a 6 hour stress test.
However, the reason I even tried over_voltage=4 instead of 6 is that with over_voltage=6, not even the fan shim would be sufficient. The temps hit 73-74 degrees when doing DietPi:s stress test (CPU was throttling a bit). When I lowered to over_voltage=4, temps are between 68-70 degrees during stress test and no thermal throttling occurred. As to what the Dietpi-overcloking profiles should look like; With over_voltage=4 it would be better to set the cpu to 1850-1900 mhz, rather than trying to raise the voltage and get even higher speeds considering not even a fan shim is enough for over_voltage=6.
There should definitely be a disclaimer with RPi4 that active cooling is highly recommended before using the overclocking profiles.
arm | core | voltage | name
1500 | 500 | 0 | (default)
1600 | 500 | 0 | (safe)
1600 | 600 | 2 | (medium GPU)
1750 | 500 | 2 | (medium ARM)
1800 | 600 | ? | (max GPU)
1875 | 500 | 4 | (medium-high ARM)
2000 | 500 | 5-6 | (max ARM)
Definitely makes sense to warn user and recommend to monitor temperatures in idle and during stress test to verify that cooling is sufficient. Overclocking is of course useless if temp raise to limit and force throttling.
Perhaps we should not offer >4 overvoltate profiles then. The profiles we offer should be safe in usual environments. If your fan does not bring down +6 voltage temps below 70°C during stress test, then this IMO is no usually reasonable profile. Probably this:
arm | core | voltage | name 1500 | 500 | 0 | (default) 1600 | 500 | 0 | (safe) 1600 | 600 | 2 | (medium GPU) 1750 | 500 | 2 | (medium ARM) 1750 | 600 | 4 | (high GPU) 1900 | 500 | 4 | (high ARM)
Looks round, always +2 overvoltage (from “safe” profile up) to raise either arm by 150 Mhz or core by 100 Mhz.
In the over clocking scene there’s usually people who wants to do inverted over clocking. Meaning they want the same performance but with less generated heat.
Therefore I tried under clocking my machines too:
over_voltage=-2 (read minus 2!) @ 1500 mhz arm cpu. It does run cool and energy efficient so far and seemingly very stable under normal use conditions. According to documentation a negative over_voltage value is possible, so I think it’d be a good idea to introduce that feature too for those trying to control the heat of the very hot RPi4.
However, there’s not much information posted on forums about other people doing under clocks so I’m not sure how stable it is to generally do that. It does work fine on two of my RPi machines though (I have only stress tested them for 5 minutes each).
Makes sense actually, especially for headless devices where the GPU has not much to do.
I read some week(s) ago that undervoltage (negative values) did not work on RPi4, but it seems then that this issue has been fixed with latest firmware.
Made some research:
Our medium ARM and high GPU profiles match to what was tested on tom’s hardware: https://www.tomshardware.com/reviews/raspberry-pi-4-b-overclocking,6188.html
There has been some report about 2000/600 with +5 voltage, but it is as well reported that whether this is stable or not (generally which overvoltage is stable with which clocks) depends quite much on the individual chip. So I think our profile is fine and failsafe so far and should work without immense cooling effort. We can always add new profiles or adjust the existing ones based on user feedback.
Profiles added: https://github.com/MichaIng/DietPi/commit/e1c5ed25dff452a8ca87ca8a4d1058334787a564
Code needs some cleanup + warning needs to be adjusted (warranty is not void by any of our profiles!), but RPi4 is in.
Excellent work MichaIng !
Looking forward to watch this go live. No more need to edit the config file myself! Thanks a lot!
I noticed Tom’s Hardware has updated their overclocking guide. The maximum overclock is now 2147 Mhz. Not sure if it has any impact on the coming change for .26 version of Dietpi. I haven’t tested it myself either.
Many thanks for heads up. Jep I as well read that they increased maximum clocks and generally allow wider ranges for some settings with ongoing firmware updates, however our profile will stay for now. The reason is not that other sets would not work as well, but that more than 1900 ARM simply requires a massive active cooling. Everyone should know that some cooling is required, however some full-covered passive cooler or usual size fan should keep idle temps in normal ranges when using our highest profile, IMO. But if power usage (=heat emission) is optimised, we can raise or add additional profiles with higher clocks.