Raspberry Pi 4 Benchmarks – Heatsink Edition

A few days ago, I ran some benchmarks in Raspberry Pi 4, and quickly found out that using the board without a cooling solution will cause serious performance issues, as in some cases my board was slower than Raspberry Pi 3 model B due to severe overheating.

After playing with LibreELEC yesterday, I’ve now reinstalled Raspbian Buster Desktop on the board, and fitted it with a largish heatsink and some old thermal paste.

Click to Enlarge

So I’ll run benchmarks again with and without heatsink. I’ll only run sbc-bench this time.

SBC Bench Installation

Open a terminal windows or connect to the board through SSH and run:

Raspbian Buster will automatically fetch the latest operating systems packages upon first boot, but apparently not the latest firmware:

So I ran rpi-update to get the very latest firmware as well, and rebooted the board:

Normally, you should not have to do it, but Raspberry Pi 4 is really new, so I expect frequent changes at the beginning. Read warning in rpi-update:

WARNING: ‘rpi-update’ updates to pre-releases of the linux
kernel tree and Videocore firmware.

‘rpi-update’ should only be used if there is a specific
reason to do so – for example, a request by a Raspberry Pi

Results with heatsink

Room temperature: 28°C. Uptime, idle temperature, and CPU freq:

Benchmark results:

Frequency/temperature monitoring during 7-zip:

It never went over the maximum 85°C temperature, and always under 80°C.

Results without heatsink

Now let’s remove the heatsink, reboot the board and wait a few minutes.

Room temperature: 28°C. Idle temperature:

So 4°C more at idle after about 3 minutes uptime without heatsink..

Benchmark results:

Throttling did occur, and indeed monitoring frequency and temperature during the benchmark shows temperature going close to 85°C, and real frequency dropping as low as 750 MHz to cool the system:

Comparison table and Pretty Chart

We can see that single thread benchmark are not affected by the presence of an heatsink, but the multi-threaded 7-zip compression is certainly impacted.

Benchmark Raspberry Pi 4 “Naked” Raspberry Pi 4 “Heatsink” Ratio
memcpy 2608.8 2540.1 97.37%
memset 3715.6 3541.8 95.32%
7-zip 4423 5397 122.02%
aes-256-cbc 16KB
64891.56k 64782.34k 99.83%

The differences for memcpy, memset, and OpenSSL are just statistical errors. But Raspberry Pi 4 with heasink is over 20% faster for 7-zip compression as it does not throttle during the test.

Click to Enlarge
Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

25 Replies to “Raspberry Pi 4 Benchmarks – Heatsink Edition”

  1. The sbc-bench output also recorded that swapping happened while running the 7-zip benchmark (RPi folks for whatever reasons love swap on SD card). If %sys exceeds 1% or %iowait exceeds 0% then benchmark execution suffered for sure. The generated numbers could be slightly higher with ZRAM or if no swapping would’ve been occurred.

    The fastest way to switch to ZRAM on Raspbian/Debian is to:

    A better variant is to rely on Stuart Naylor’s replacement https://github.com/StuartIanNaylor/zram-swap-config though

    Also still undervoltage / frequency capping was reported. Based on your unboxing pictures it seems you’re not using the official USB-C PSU from RPi Trading?

    1. Yes, I’m using the official USB-C PSU.

      The undervoltage bit is set to 0. Wouldn’t that mean there hasn’t been any undervoltage.
      Can frequency capping be related to temperature instead of undervoltage?

        1. I have not looked into this as much as you did, but another reason that makes me believe it’s not related to undervoltage is that there’s an “under-voltage” bit that’s set to zero.

  2. As 7zip goes south with each consecutive run on ‘naked’, and the 3rd runs on heatsink/naked are scored ~5300/~4000 respectively, it’d be reasonable to expect a heatsink/naked ratio of well over 25% in the long run on this task.

      1. I am also for the liquid nitrogen test. I think it’s the next thing for the rpi and pretty soon everyone will be doing it.

  3. The Raspberry Pi Foundation has a new firmware for the VLI USB controller that is said to lower idle power consumption by 10%. They’ll release it in a few weeks.

    1. When looking at the VL805 the chip itself seems not to be the problem: https://miro.medium.com/max/1400/1*KedwLPE9eXoeuwdciZpE0Q.png

      So most probably PCIe power management related? Ah, yes, lspci -vvv confirms ASPM Disabled (Active-State Power Management):

      1. Got the new firmware. Idle temperature is 3 to 4C lower, during benchmark ~5C lower. But still throttle with 7-zip multi-threaded, albeit during third run only. Same 28C room temperature. I cannot post about it yet, but you were onto something:

    1. Jean-Luc,

      Thanks for carrying out this RPi4 test. I’m so glad other people have found the same I have have regarding the device. When I first started asking questions and alerting people [on June 26, 2019] of the large amounts of heat that this device produces, not many believed me, and I was labelled a “Troll” by some others. Anyway, I’ve fitted a 28mm x 28mm x 20mm aluminium heatsink to my Raspberry Pi 4 Model B with a 30mm x 7mm @ 5v fan on top of it. The system is really stable now, and very fast. Thermal status of the CPU is ~35’C when idle at the command prompt and ~45’C when compiling binaries from source code using gcc -j6. I’m running Slackware ARM, not Raspbian. I figured, if I was going to install anything it would be a bona fide OS and not some Debian rip-off that’s been hacked to bits so it will actually run on the device. The RPi closed-source firmware doesn’t impress me either. Anyway, I like the work you’ve done. Your results are very similar to my findings on the Raspberry Pi 4 Model B.

      Cheers, Exaga

  4. I’ve just ran the benchmark as described and here are the results: http://ix.io/1TWC

    I’m using a Wicked Aluminum enclosure which uses passive cooling to keep the temperatures down. It also helps that my workbench is made of metal, so heat from the case is passed on to the bench itself.

    1. No overheating, but for some reason all first runs of 7-zip were slow:

      1. I actually did not take a closer look at the the results before posting, but you’re right indeed! I think it might has something tot do with the governor’s settings. On Raspbian the default governor is “ondemand”. I’ve set it to “performance” and did another run which shows more consistent numbers: http://ix.io/1TZA. The room temperature was ~26C.

        I also noticed something peculiar. If the SoC runs too cold, it also shows lower clock frequencies. When I initially fired it up, the sun hasn’t touched my workbench yet, so it was pretty cold to the touch. Since the Raspberry’s enclosure is made from 100% aluminium, it transferred its heath to my metal workbench and wasn’t able to reach an optimal operating temperature. Take a look at the details of this specific run here: http://ix.io/1TYU

        1. It could also be something completely different, like systemd having fun in the background, or a crontab running stuff like a package update system. All of these will result in the measured CPU speed to be lower if the thread is scheduled out, and might explain why the measured frequencies are only slightly lower and not stable.

          1. You would think so, but I was able to reproduce it by keeping the case (too) cool. When the SoC’s temperature drops below 33°C it doesn’t reach its maximum clock frequency (2 GHz).

Leave a Reply

Your email address will not be published.