performance

tl;dr Raspberry Pi engineers tweaked SDRAM timings and other memory settings on the Pi, resulting in a 10-20% speed boost at the default 2.4 GHz clock. I of course had to test overclocking, which got me a 32% speedup at 3.2 GHz! Changes may roll out in a firmware update for all Pi 5 and Pi 4 users soon.

My quest for the world record Geekbench 6 score on a Pi 5 continues, as a couple months ago Martin Rowan used cooling and NUMA emulation tricks to beat my then-record score.

I had to pause some of my work getting a current-gen AMD graphics card running on the Pi 5 and testing a 192-core AmpereOne server to quickly post on the M4's efficiency.

I expected M4 to be better than M1/M2 (I haven't personally tested M3), and I hoped it would at least match the previous total-system-power efficiency king, a tiny arm SBC with an RK3588 SoC... but I didn't expect it to jump forward 32%. Efficiency gains on the Arm systems I test typically look like 2-5% year over year.

The M4 mini I just bought reaches 6.74 Gflops/W on the HPL benchmark.

UPDATE 2024-11-20: I re-ran all my tests without my 10 Gbps Ethernet plugged in, and the efficiency is even better. I also re-tested LLM performance, and made this quick video:

Since boosting my Pi 5 from the default 2.4 GHz clock to 3.14 GHz on Pi Day, I've wanted to go faster. Especially since many other users have topped my Geekbench scores since then :)

In March, Raspberry Pi introduced new firmware that unlocked frequencies above 3,000 MHz for overclocking. This summer, NUMA Emulation patches boosted performance another 5-10% through memory access optimizations.

But even with a golden sample Pi 5, I haven't seen anybody go much beyond 3.1 or 3.2 GHz. The problem seemed to be power supply—the Pi's firmware limits the SoC to a maximum of 1.000V.

...and it's not just for Pi Day.

After posting my deep-dive into the Pi 5's new BCM2712 and RP1 silicon this morning, someone linked me to this GitHub issue: Raspberry Pi 5 cannot overclock beyond 3.0GHz due to firmware limit(?).

For the past few weeks, a few blog readers (most notably, tkaiser—thanks!) commented on PLLs, OPP tables, and DVFS and how something seemed a little off with the 3.0 GHz CPU limit—which was apparently recommended by Broadcom, according to that GitHub issue.

But today, @popcornmix generated a test firmware revision without the 3.0 GHz limit, and zealous overclockers can get to pushing the clocks higher.

Silicon lottery.

Now that the Raspberry Pi 5s been readily available (at least in most regions) for a few months, more people started messing with clocks, trying to get the most speed possible out of their Pi 5s.

Unlike the Pi 4, the Pi 5 is typically comfortable at 2.6 or even 2.8 GHz, and some Pi 5s can hit 3.0 GHz (but no higher—more on why tomorrow well... this limit may be able to be lifted).

After some testing, I found the default 2.4 GHz clock on the Pi 5 is pretty much the efficiency sweet spot, and after a lot more testing recently, I can confirm that's still the case, testing a number of Pi 5 samples.

tl;dr: 52Pi and Seeed Studio's water cooling solution for the Raspberry Pi 5 can be fun, and works better than any other solution—but at a steep price, and with a number of annoying quirks.

A few months ago, 52Pi reached out and asked if they could send a new water cooling kit they were working on for the Raspberry Pi 5. At the time, the hope was we could figure out a way to get very high overclock with adequate cooling.

Unfortunately—for reasons I'll explore more soon—the Pi 5 can't overclock beyond 3.0 GHz (it's not physically possible). Some of why is explained in my blog post Overclocking and Underclocking the Raspberry Pi 5.

But water cooling is still fun, and the product is in production now, so I figured I'd still give it a fair shot, and see if I thought it might be worth buying for certain niche use cases.

In my video about the brand new Raspberry Pi 5, I mentioned the new external PCIe port makes it possible to boot the standard Pi 5 model B directly off NVMe storage—an option which is much faster and more reliable than standard microSD storage (even with industrial-rated cards!).

Enabling NVMe boot is pretty easy, you add a line to /boot/firmware/config.txt, modify the BOOT_ORDER in the bootloader configuration, and reboot!

I recently had a server with some bandwidth limitations (tested using scp and rsync -P), where I was wondering if the problem was the data being transferred, or the server's link speed.

The simplest way to debug and verify TCP performance is to install iperf3 and run an iperf speed test between the server and my computer.

On the server, you run iperf3 -s, and on my computer, iperf3 -c [server ip].

But iperf3 requires port 5201 (by default) to be open on the server, and in many cases—especially if the server is inside a restricted environment and only accessible through SSH (e.g. through a bastion or limited to SSH connectivity only)—you won't be able to get that port accessible.

So in my case, I wanted to run iperf through an SSH tunnel. This isn't ideal, because you're testing the TCP performance through an encrypted connection. But in this case both the server and my computer are extremely new/fast, so I'm not too worried about the overhead lost to the connection encryption, and my main goal was to get a performance baseline.

In the pursuit of doing crazy things on a Raspberry Pi, my latest endeavor was to see if I could consistently pipe more than a gigabit per second of traffic through WiFi using a Raspberry Pi.

In the past, I had some faltering attempts where sometimes things would work—sort-of—using WiFi 6 (802.11ax, 40 MHz bandwidth, 2x2) using an Intel AX200 M.2 card on the Raspberry Pi Compute Module 4.

Recently I was doing some benchmarking on my Ubuntu 22.04 PC, and as part of that benchmarking, I tried setting the CPU performance profile to performance. In the old days, this was not an issue, but it seems that modern Ubuntu only 'knows' about balanced and power-saver. Apparently performance is forbidden these days!

$ powerprofilesctl list
* balanced:
    Driver:     placeholder

  power-saver:
    Driver:     placeholder

The problem was, I had set the profile to performance:

$ powerprofilesctl set performance

But suddenly the 'Settings' GUI app would no longer open (at least not after I had opened it and clicked into the 'power' section). A reboot didn't work, and even reinstalling control center (sudo apt-get install --reinstall gnome-control-center) didn't help!

When I tried opening the settings GUI from the command line, I got the following critical error: