I tried everything but couldn’t turn this Raspberry Pi 5 into the World’s Fastest Pi 5. Unfortunately, we can’t quite claim that title … despite the software reporting 4 GHz.

https://www.youtube.com/watch?v=qzy24LkL_4Q&feature=youtu.be

Introduction

We tried everything to make our Pi the fastest Pi in the world. That includes changing the operating system, subzero cooling with liquid nitrogen, boosting the power circuitry, and even swapping out the crystal oscillator.In this blog post I try to share some of the findings and insights from the several weeks of Pi hacking in collaboration with ElmorLabs.

Let’s start where we left off: in SkatterBencher #77 I overclocked the Raspberry Pi 5 to 3 GHz with a slightly improved air cooler. It appears that the PMIC voltage controller is a key limiting factor for achieving higher frequencies. Not only does the PMIC impose voltage configuration limitations but we also saw the Pi shut down at high power consumption levels.

Therefore, I decided to beef up the power circuitry using the ElmorLabs AMPLE-X1. But I’ll get back to that later, because the first concern for maximizing performance is the operating system.

Raspberry Pi OS + NUMA Patch

In preparation for the record attempt, it’s important to prepare the operating system first. Coming from Ubuntu in my SkatterBencher guide, there’s two things we can improve:

1. Change to the official Raspberry Pi OS, and
2. Apply the NUMA patch

The official Raspberry Pi operating system can easily be downloaded from the website. Alternatively, you can also use the Raspberry Pi Imager software which does all the hard work for you.

I first learned about the NUMA patch when discussing Raspberry Pi overclocking on the Tom’s Hardware Guide The Pi Cast #181 a couple of months ago. It boils down to this: NUMA emulation enables the BCM2721 memory controller to better utilize parallelism in physical memory chip organization.

I followed Jeff Geerling’s guide on enabling the NUMA patch. Combining the Raspberry Pi operating system and applying the NUMA emulation patch improved the benchmark performance significantly.

Liquid Nitrogen Cooling

The next step of preparing the Raspberry Pi for higher voltages and frequencies is ensuring we have superior cooling. Preferably, extreme cooling like liquid nitrogen. The place to be for liquid nitrogen testing in Taipei, Taiwan, is of course the ElmorLabs office.

The Raspberry Pi 5 has a small-footprint PCB with quite a lot of tall components spread around the PCB. So, we can’t use a regular container like our AI LN2 container or the ElmorLabs Volcano. However, we found this tiny chipset LN2 pot. This container is heavy enough that it can just sit on top of the SoC and provide enough cooling even at ambient. After all, the SoC is barely using any power.

I first ran Geekbench at 3200 MHz as a performance sanity check and I achieved 1000 in single-core and 2000 in multi-core in for the first time.

Then, I tried increasing the operating frequency with low ambient temperatures of 20 degrees Celsius. However, as you can see, with ambient temperatures I could only set the clock to 3600 MHz. Once I tried 3700 MHz the Pi would lock up.

Reducing the temperature to minus 40 degrees resulted in the same type of crash: the Pi just locks up at 3.7 GHz. Strange! I also hooked up the ElmorLabs EVC2 to talk to the Renesas PMIC directly and elevate every voltage rail. However, none of them seemed to have any impact on the maximum clock frequency.

For those interested: the Raspberry Pi 5 only starts having operating problems around -90 degrees Celsius. Not bad at all!

Hitting a frequency wall at any temperature is  rather odd behavior because any modern SoCs should normally scale with both temperature and voltage, unless there’s an external bottleneck imposing a limit. But the lack of temperature scaling suggests that perhaps there would also be a lack of voltage scaling.

But, there’s only one way to find out!

Raspberry Pi “Amplified”

In the SkatterBencher guide, I mention that the Raspberry Pi is shutting down in high load scenarios which use the NEON instructions.

“If we have a closer look at the PassMark benchmark, we find that the benchmark crashes specifically at the NEON sub-test. […] If we track the current, voltage, and power of the VDD_core during the workload, we find that the NEON subtest is significantly more power-intensive than any other benchmark. We can see peak current exceeding 15 amps and the power consumption exceeding 18 watts.

When the benchmark crashes, the Raspberry Pi shuts down, and we can’t even communicate with the PMIC unless we manually press the power button. This suggests the instability is not caused by too high frequency, but perhaps some other mechanism such as over-current or over-temperature protection. Based on the voltage telemetry provided by the Python script, it doesn’t seem like it’s an under-volt issue. However, unfortunately, the PMIC debug options are not available at the moment.”

SkatterBencher #77: Raspberry Pi 5 Overclocked to 3000 MHz

To address this problem – as well as the 1.2V voltage limit – we need to beef up the power circuit. And, once again, ElmorLabs comes to the rescue with the Ample-X1 Power Card.

ElmorLabs AMPLE-X1

The ElmorLabs AMPLE-X1 is a power card that uses a single-phase step-down buck converter. It is optimized for operating from a 12V power supply but can work with down to 4.5V input. It achieves up to 91.7% efficiency and the parameters can be monitored and controlled digitally by connecting it to EVC2.

To hook up the AMPLE-X1 to the Raspberry Pi 5, we need to perform some hard-to-reverse and definitely-warranty-voiding modifications.

1. Remove the inductors of the 4-phase SoC to disconnect the PMIC from the SoC.
2. Scratch off the PCB mask to expose more of the copper plane for Vcc and Gnd.
3. Solder thick, short wires between the Raspberry Pi and the AMPLE-X1.
4. Make sure the AMPLE-X1 is set by default around 1.0V (it can provide up to 5.0V!)

Once that’s done, it’s time to try if the Pi still boots up. This is not guaranteed because sometimes the SoC has two-way communication with the PMIC to ensure correct bootup procedure. Luckily, it works. The important step is to turn on the AMPLE-X1 power to the SoC before connecting the USB Type-C to power the other rails and initiate bootup.

Now, we can use the ElmorLabs EVC2 to adjust the output voltage as well as monitor the output current and power. You can use the EVC2 on a secondary system, like a Windows laptop, or use the unofficial Linux package available for download from the ElmorLabs discord here: https://discord.com/channels/514312075686838282/830630797962641468/1204348733249159218 (backup).

Here’s an example of the AMPLE-X1 peaking at 25.5W during a Passmark run.

With the beefed-up power circuit, we can now increase the voltage to get higher frequency. We tried increasing the voltage from 1.2V all the way up to 1.55V. Unfortunately, we didn’t achieve a single additional step of MHz. This is, unfortunately, aligns with the lack of temperature scaling.

But why?

Crystal Oscillator

There are many reasons why the SoC frequency wouldn’t scale with temperature or voltage. For example, it could be a PLL locking problem like we’ve seen with Intel Tiger Lake. Or it could be that a specific IP block linked to the Arm cores is also getting overclocked. Or, it could be a specific PLL ratio being unstable.

Unfortunately, most of these issues are hard to debug without the proper development tools. However, we can try one last thing to see if maybe the Arm core PLL is causing issues: swapping out the crystal oscillator. The idea is simple: we swap the fixed crystal oscillator with a variable oscillator. That allows us to change the PLL ratio for frequencies exceeding 3.6 GHz.

ElmorLabs ECB

The default clock crystal is a 54MHz crystal which is on the backside of the PCB. It can be removed with some heat. Next, we replace it with the ElmorLabs External Clock Board. Now, we can adjust the input clock lower or higher than the default 54 MHz.

Upwards, we immediately ran into a limitation of around 56 MHz. However, downwards adjustment was much easier, and the Raspberry Pi 5 could go as low as 46 MHz.

With 46 MHz, we can set the Arm frequency to 4000 MHz. As you can see, the Broadcom vcgencmd tool also reports as 4 GHz. But of course, the real frequency is much lower because the crystal oscillator reference clock is lower. The actual frequency is 4,000 / 54 x 46 = 3,407 MHz.

Again, we run into the same frequency wall as we saw with temperature and voltage adjustments: about 3.4 GHz for benchmarks and 3.6 GHz as maximum configurable frequency.

Oh, I did try to run Geekbench at the fake 4 GHz and, good news, it was able to catch the result isn’t legitimate. Great job!

Conclusive Thoughts

So, that’s basically it … we’ve tried everything we could reasonably come up with to push the Raspberry Pi 5 to 4 GHz. But despite the much lower temperatures, much higher voltages, and even a different crystal oscillator … 3.6 GHz is the highest possible frequency.

But all things considered, I’m still very happy to have put in the time and effort to learn about Raspberry Pi overclocking. It gave me the opportunity to learn more about Linux and ARM, as well as pursue really advanced hardware modifications. I see this experience as a pivotal work forming a foundation for future experiments.

I want to thank Jon from ElmorLabs for all the help and tools provided for this overclocking experiment. Without his help, this project would not have been possible!

I thank you for reading and the Patreons for the support. If you have any questions or comments, please drop them in the comment section below. 

See you next time!