Hi!
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:
over_voltage=2
arm_freq=1750
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.
aftensleuk
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).
over_voltage=4
arm_freq=2000
aftensleuk
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 
.
MichaIng
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)
aftensleuk
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.
MichaIng
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).
aftensleuk
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!
MichaIng FYI
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.
https://www.tomshardware.com/reviews/raspberry-pi-4-b-overclocking,6188.html
aftensleuk
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.
Resurrecting this thread to report a bug.
I’ve already noticed it a few years ago and reported it somewhere in connection with rpi-monitor but it led to nothing.
The clock is not working correctly when running Rpi4 with an overclock profile from dietpi. The difference seems to be related to the overclock amount. Here is a screenshot of one minute measured using a phone stopwatch while tracking the pi at 1500 MHz:
1 pi minute = 1 real minute
And here overclocked to 1800 MHz:
52 pi seconds = 1 real minute
Rpi monitor graphs were cut around the pi midnight and jagged when continuous time sync was enabled. Indicating a lot of corrections being made.
It would be nice to be able to use the profile. So far I’ve been only using the undervolt profile and it was stable (but it doesn’t change the max frequency). I tried to read about this and was led to the SPI clock frequency but I’m not sure this even exists on raspberry pi 4.
I know there are cases where the system clock runs slower, when the CPU frequency is below a certain limit. 300 MHz used to be a minimum which still works, but there are individual cases where 600 MHz needed to be the minimum, to have normal system clock speed. So it differs between individual chips/batches.
However, I never heard from a case where the clock ran above normal speed, when running on higher frequencies, especially since RPi OS runs on 1.8 GHz by default, on all recent PCB revisions, just like RPi 400 does. Does it run faster as well when you reset the overclocking profile and instead add arm_boost=1 to /boot/config.txt? The cpu command should verify that it runs on 1.8 GHz, and this is how RPi OS is shipped.
I am not sure how you measure the RPi clock speed. So you see larger time shifts in system logs when systemd-timsyncd does a sync? I would probably run the date command when starting the watch, let it run for 5 minutes to reduce errors, and run the date command again when stopping the watch.
But I wrote that 1 real minute is 52 pi seconds, so the clock runs slower. And yes, it runs at 1.8 GHz when the profile is active. I’ll add the arm boost then.
To measure the clock, I used split screen. I started the stopwatch when the clock was at full minute (00) and let it run for 1 minute (real time), then made a screenshot of both apps in split screen when the stopwatch hit 1 minute. So the phone stopwatch shows real time. Which means that the rpi clock runs slow when overclocked. I could run this for 5 min but don’t see the point as the difference is large enough.
I think that only the newer batches of rpi4 run at 1.8 GHz, not sure which one is mine. Bought it 1st half of 2020 so possibly the earlier batch.
Ah, you used rpi-monitor. I don’t know its code, but it may not represent the actual RPi system clock, but just be some PHP application timer, with one system timestamp as starting point. It may not even run on the RPi, but in the browser (JavaScript), though the speed difference indicates that it does run on the RPi. However, software timers can be/run off for various other reasons.
Please check whether the actual RPi system clock, e.g. via date command from console, really runs faster. Else it is a software bug/limitation.
Rpi monitor is irrelevant now. I can dig out the post if you need it but I don’t see why. The problem is the same. The screenshots I sent are from btop.
The lines were jagged because the time was continuously being corrected by timesyncd when I activated it. But that was just for background, to say that the same thing still happens.
The max frequency was faster but the minimum clock was at 300 MHz, it was idling with schedutil so did not run at 1.8.
I just did some tests and this is what I found:
When arm_boost=1 and the min frequency is 300, the clock does run slow:
But when I modify the minimum frequency (keeping
arm_boost=1) to 600 MHz, the clock runs normally:
Again, the minimum doesn’t need to be 600 MHz when the max frequency is 1.5 GHz (then it can be 300 MHz and the clock runs fine). Weird.
Anyway, thanks for the free performance!