Overclocking the Raspberry Pi Compute Module 4

People have been overclocking Raspberry Pis since the beginning of time, and the Raspberry Pi 4 is no exception.

I wanted to see if the Compute Module 4 (see my full review here) could handle overclocking the same way, and how fast I could get mine to run without crashing.

There's a video version of this blog post, if you'd like to watch that instead:
Raspberry Pi Compute Module 4 OVERCLOCKED.

I have a giant Noctua NF-P12 fan that I can plug right into the J17 4-pin fan connector built into the Compute Module 4 IO Board, and for all these tests I let it run full blast, moving a lot of air over the board on my desk. Without active cooling, the SoC overheats pretty quickly under load—though you probably don't need this much cooling!

Raspberry Pi Compute Module 4 CPU Overclock Setup with Noctua Fan

At some point I'm going to work on a script that controls the fan's speed using the IO Board's built-in PWM-enabled fan controller chip which is accessible over I2C bus 10. But for now it's full speed ahead!

A few points of reference:

  • You can monitor the CPU frequency with: watch -n 1 vcgencmd measure_clock arm
  • You can monitor the CPU temperature with: watch -n 1 vcgencmd measure_temp
  • You can monitor whether the CPU is throttled with: watch -n 1 vcgencmd get_throttled

Editing the config - setting up the overclock

I wanted to get a nice, clean 2.0 GHz out of my Compute Module; it's default clock maxes out at 1.5 GHz, and getting a solid 30% speedup feels pretty good to me—again, assuming an adequate amount of cooling, and a reliable power supply.

So I edited the /boot/config.txt file, and uncommented the arm_freq= line. I set that section of the file to contain the following:

#uncomment to overclock the arm. 700 MHz is the default.

The over_voltage allows the Pi to give the SoC a little extra power, required when overclocking the CPU frequency. And the arm_freq sets a new maximum upper frequency limit. The highest allowed frequency is currently 2147 (2.147 GHz), though I'm not sure why it's capped at exactly that frequency (the docs and blog posts are mum on that topic).

You could also set the gpu_freq= value to up to 750 to boost the GPU clock, but I'm happy with a clean 2.0 GHz and the GPU bits running at their default 500 MHz frequency, so I saved and closed the boot config, then rebooted the Pi with sudo reboot.

If you want to 'turn it up to 11' (go as fast as the Pi 4 / CM4 can go), set the following options:


Once rebooted, I monitored the frequency as I ran sudo apt-get update, and confirmed it reached up to 2.0 GHz under load:

$ vcgencmd measure_clock arm

Note: If you set an overclock and your Pi fails to boot, you can plug in a keyboard and hold down the Shift key while booting to disable overclock. Alternatively, pop the boot volume into another computer (or if using a CM4 with eMMC, set it in mass storage mode using usbboot), and comment out the overclock lines in the /boot/config.txt file.

Testing the performance with Phoronix

I wanted to see how the performance at 2.0 GHz compared to 1.5 GHz, so I ran the same three tests using Phoronix that I did in my initial CM4 review, and here are the results:

Raspberry Pi Compute Module 4 2 GHz overclock benchmark results

The speedup in each benchmark was almost exactly 28%, which is expected since the clock speed difference between 1.5 and 2.0 GHz is—you guessed it—28%!

Note: If you want to run the exact same test suite, you can use the same benchmark shell script I used: pi-general-benchmark.sh.

Measuring the Temperature

During the benchmarks, I plotted the temperature by logging it to a CSV file every second with a really simple Python script:

from gpiozero import CPUTemperature
from time import sleep, strftime, time

with open("/home/pi/cpu_temp.csv", "a") as log:
    while True:
        cpu = CPUTemperature()
        log.write("{0},{1}\n".format(strftime("%Y-%m-%d %H:%M:%S"),str(cpu.temperature)))

You can save that as temp_log.py, then run it with python temp_log.py in Terminal during the benchmarking.

And here's the temperature log during the Phoronix CPU benchmarking:

Raspberry Pi Compute Module 4 CPU temperature under load with overclock

You can see that the temperature never went above 63°C, and I confirmed there was no throttling at any time. The CPU got the hottest during the first three H.264 compression tests, but was able to keep its cool (with the giant Noctua fan) throughout the other two tests, where it hovered around 40°C.

Here's a thermal image of the entire board when it was under the highest load:

Raspberry Pi Compute Module 4 55°C thermal image of SoC with kapton tape

For this thermal image, I put a little kapton tape on top of the SoC so the temperature reading would be more accurate. It was only about two degrees lower than what vcgencmd measure_temp was reporting.

Just to test how quickly the Pi would overheat and throttle without any cooling (and no enclosure), I ran the same benchmark and measured the temperature:

Raspberry Pi Compute Module 4 CPU Temperature overheat with no fan

It only took about 3 minutes before the Pi started throttling the CPU to protect itself from overheating. So active cooling (or at least a massive heatsink) is a hard requirement when overclocking!

Overclock and NVMe storage performance

One thing I remembered reading in almost all the posts about the SoC's overclocking abilities was that overclocking the GPU could also lead to increased performance in other areas besides just graphics rendering.

Stretching that idea a bit, I wondered if the CPU clock and performance affected the performance of NVMe storage via the PCIe lane at all—and much to my surprise, it did!

I re-ran all the disk performance benchmarks from my review with the 2.0 GHz overclock on my Samsung 970 EVO Plus using this NGFF PCIe NVMe adapter, and now the numbers for every type of disk operation saw a measurable improvement:

Raspberry Pi Compute Module 4 NVMe overclocked performance benchmark

I wanted to make sure the benchmark wasn't an anomaly, so I ran the same benchmarks (three times per benchmark) two times in each condition (e.g. run all benchmarks with no overclock, then with overclock, then without, etc.), and the numbers were within about 1% margin of error.

So I can say with some authority that if you want to make bleeding-edge NVMe storage even faster than it already was on the stock Compute Module 4, overclock it to 2.0 GHz and you'll get an extra 15% speedup.

I also ran the benchmarks on the same drive over USB, but the results were the same with or without the overclock. That makes sense, since USB 3.0 runs with a different chip controlling the access (in my case, the VL805 inside my Syba USB 3.0 PCIe card).


I think it's safe to say the Compute Module 4 hardware handles overclocking as well as a Pi 4 model B, which isn't surprising given that the chips are almost identical (even if the arrangement on the board is slightly more compact).

And if you want to have the fastest possible storage, you should overclock the CPU—and make sure you have some sort of cooling in place to prevent throttling.

Are there any other things you want me to test on the CM4? I'm planning on testing a few more PCIe cards, including a 1x Nvidia GPU and a 4x Intel NIC, and I'll definitely share the testing results when I get them!


Hello I have verified that my rp4 increases the memory speed using the 64-bit kernel. It would be interesting if CM4 is the same.

That's a good point. I should grab the latest 64-bit beta Pi OS version and re-run the tests there to see if there's a major difference. There was when I ran similar comparisons on the CM3+ and Pi 4 B.

I am at a loss at how you got 28 % for the clock speed difference. 500Mhz is either 33% of 1500MHz or 25% of 2 GHz. What am I missing? Thanks

((1500-2000) / ((1500+2000)/2)) * 100 = 28.5714%

That's the difference though. Not the percent change from 1500 to 2000, which would be 33.3333%

I'd be very interested in the power/current consumption of the CM4 in different scenarios (different load on different number of cores, different frequencies, only GPU, only CPU, radio on/off, ethernet on/off etc.)
Would it be possible to measure these things? I think the CM4 would be great for portable devices, especially when undervolted/underclocked.


You say that "It only took about 3 minutes before the Pi started throttling the CPU to protect itself from overheating. So active cooling (or at least a massive heatsink) is a hard requirement when overclocking!", but where would we get these?

I don't trust myself with a hacksaw, so I'm reliant on commercial solutions. I'd also prefer active cooling, if possible.

I have seen many on Amazon and even the sites that sell them in the first place. If you search "GeeekPi fan" on Amazon they have a number of heatsinks with fans.

I bought one of those and the boss in the heat sink was milled in the wrong position to contact the CPU. It will be on its way back as soon as I can get to a drop point.

Thank you Jeff for this article! It would be great for comparison if you could provide another curve for the standard clocked CM4 in your first "Temperature over Time" plot.

In addition I would be interested in the regular thermal situation of an CM4 without putting a giant Noctua in front of it! :-)


I just wanted to ask real quick if you could make a video or short tutorial whatever for controlling the J17 Fan Header on IO Board.
I have no clue on how to do that. I know that I have to enable I2C which I did but how can I tell the CM4 that it controlls the header?!

The internet doesn't really give me answers as well (or I'm not good enough at googling :rofl:) :/


I have an idea as to why the max clock speed during your test was 2147 MHz. The first four digits of the 32-bit integer limit are 2147, meaning if you can input the clock speed in Hz you might be able to get the full 2,147,483,647 Hz that it might be possible.

Any idea how to control the fan on the compute module 4 The raspi fan control under performance expects gpio connection?

Hey, Jeff ! I discovered some time ago the bcmstat script installed by default on libreelec. Give it a try, it's nice for these kind of tests. I won't paste any link here, but you could find it on GitHub, made by MilhouseVH.

Oh nice! I like it, will definitely be testing that out and seeing how well it behaves during my testing in the future. I love how it also integrates IRQs since that can be a big problem with network and PCIe testing.