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.
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:
1 |
wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh |
Raspbian Buster will automatically fetch the latest operating systems packages upon first boot, but apparently not the latest firmware:
1 2 3 4 |
/opt/vc/bin/vcgencmd version Jun 20 2019 16:04:31 Copyright (c) 2012 Broadcom version 407b1da8fa3d1a7108cb1d250f5064a3420d2b7d (clean) (release) (start) |
So I ran rpi-update to get the very latest firmware as well, and rebooted the board:
1 2 3 4 |
/opt/vc/bin/vcgencmd version Jun 26 2019 17:42:42 Copyright (c) 2012 Broadcom version 1186f932808ed601ddd583a30a3ce055477b1a26 (clean) (release) (start) |
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
engineer.
Results with heatsink
Room temperature: 28°C. Uptime, idle temperature, and CPU freq:
1 2 3 4 5 6 |
pi@raspberrypi:~ $ uptime 17:00:51 up 2 min, 3 users, load average: 0.37, 0.33, 0.13 pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd measure_temp temp=60.0'C pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd measure_clock arm frequency(48)=600169920 |
Benchmark results:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
sudo /bin/bash ./sbc-bench.sh -c sbc-bench v0.6.7 Installing needed tools. This may take some time... Done. Checking cpufreq OPP... Done. Executing tinymembench. This will take a long time... Done. Executing OpenSSL benchmark. This will take 3 minutes... Done. Executing 7-zip benchmark. This will take a long time... Done. Checking cpufreq OPP... Done. It seems neither throttling nor frequency capping has occured. Memory performance: memcpy: 2540.1 MB/s memset: 3541.8 MB/s (0.4%) 7-zip total scores (3 consecutive runs): 5520,5329,5342 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 62337.00k 76517.57k 83103.06k 84397.40k 85174.95k 85103.96k aes-128-cbc 62385.73k 76696.34k 82954.50k 84633.94k 85035.69k 85169.49k aes-192-cbc 56248.36k 67203.52k 72105.90k 73188.35k 73454.93k 73564.16k aes-192-cbc 56125.90k 67502.17k 71853.82k 73263.45k 73610.58k 73422.17k aes-256-cbc 51001.95k 59901.03k 63540.65k 64509.95k 64828.76k 64875.18k aes-256-cbc 50713.81k 60062.34k 63573.93k 64478.89k 64927.06k 64782.34k Full results uploaded to http://ix.io/1MUi. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL. |
Frequency/temperature monitoring during 7-zip:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
pi@raspberrypi:~ $ sudo ./sbc-bench.sh -m Time fake/real load %cpu %sys %usr %nice %io %irq Temp VCore 17:21:17: 1500/1500MHz 4.00 25% 1% 22% 0% 1% 0% 76.9°C 0.8613V 17:21:22: 1500/1500MHz 4.00 98% 1% 96% 0% 0% 0% 78.4°C 0.8613V 17:21:27: 1500/1500MHz 4.08 69% 4% 64% 0% 0% 0% 78.4°C 0.8613V 17:21:37: 1500/1500MHz 4.07 82% 6% 56% 0% 19% 0% 76.0°C 0.8613V 17:21:46: 1500/1500MHz 4.43 82% 3% 35% 0% 43% 0% 75.0°C 0.8613V 17:21:51: 1500/1500MHz 4.31 33% 3% 13% 0% 16% 0% 73.0°C 0.8613V 17:21:56: 1500/1500MHz 4.13 49% 1% 47% 0% 0% 0% 73.5°C 0.8613V 17:22:02: 1500/1500MHz 4.12 84% 3% 65% 0% 16% 0% 77.9°C 0.8613V 17:22:07: 1500/1500MHz 4.27 51% 2% 49% 0% 0% 0% 75.5°C 0.8613V 17:22:12: 1500/1500MHz 4.25 89% 3% 85% 0% 0% 0% 77.4°C 0.8613V 17:22:17: 1500/1500MHz 4.22 94% 2% 91% 0% 0% 0% 78.9°C 0.8613V 17:22:22: 1500/1500MHz 4.13 80% 3% 77% 0% 0% 0% 78.4°C 0.8613V 17:22:27: 1500/1500MHz 4.12 96% 1% 94% 0% 0% 0% 79.4°C 0.8613V 17:22:32: 1500/1500MHz 3.87 77% 4% 72% 0% 0% 0% 77.9°C 0.8613V 17:22:37: 1500/1500MHz 3.80 84% 3% 80% 0% 0% 0% 78.4°C 0.8613V 17:22:52: 1500/1500MHz 4.53 91% 10% 71% 0% 9% 0% 76.4°C 0.8613V 17:22:58: 1500/1500MHz 4.33 54% 3% 36% 0% 14% 0% 75.5°C 0.8613V 17:23:03: 600/ 600MHz 4.30 77% 4% 61% 0% 11% 0% 76.0°C 0.8613V 17:23:08: 1500/1500MHz 4.28 85% 6% 76% 0% 2% 0% 76.9°C 0.8613V |
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:
1 2 3 4 5 6 |
pi@raspberrypi:~ $ uptime 17:30:16 up 4 min, 4 users, load average: 0.05, 0.18, 0.09 pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd measure_temp temp=64.0'C pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd measure_clock arm frequency(48)=600169920 |
So 4°C more at idle after about 3 minutes uptime without heatsink..
Benchmark results:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
sudo /bin/bash ./sbc-bench.sh -c sbc-bench v0.6.7 Installing needed tools. This may take some time... Done. Checking cpufreq OPP... Done. Executing tinymembench. This will take a long time... Done. Executing OpenSSL benchmark. This will take 3 minutes... Done. Executing 7-zip benchmark. This will take a long time..../sbc-bench.sh: line 600: 26143 Killed taskset -c 0 "${SevenZip}" b -mmt 1 >> ${TempLog} Done. Checking cpufreq OPP... Done. ATTENTION: Throttling and frequency capping has occured. Check the log for details. Memory performance: memcpy: 2606.8 MB/s (0.1%) memset: 3715.6 MB/s (0.6%) 7-zip total scores (3 consecutive runs): 5010,4199,4060 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 62618.39k 76668.97k 83098.11k 84445.18k 85207.72k 85256.87k aes-128-cbc 55602.85k 73856.09k 82227.71k 84523.35k 85125.80k 85185.88k aes-192-cbc 56274.63k 67320.43k 72087.98k 73332.39k 73457.66k 73602.39k aes-192-cbc 50073.79k 65060.65k 71326.63k 73138.52k 73220.10k 73400.32k aes-256-cbc 50936.85k 60008.47k 63549.78k 64555.69k 64913.41k 64935.25k aes-256-cbc 50874.31k 60056.68k 63686.74k 64486.06k 64891.56k 64815.10k Full results uploaded to http://ix.io/1MUy. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL. |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
pi@raspberrypi:~ $ sudo ./sbc-bench.sh -m Time fake/real load %cpu %sys %usr %nice %io %irq Temp VCore 18:40:40: 1500/1500MHz 4.46 18% 1% 15% 0% 1% 0% 79.9°C 0.8595V 18:40:45: 1500/1500MHz 4.69 50% 2% 1% 0% 46% 0% 77.9°C 0.8595V 18:40:55: 1500/1500MHz 4.79 80% 5% 42% 0% 32% 0% 80.3°C 0.8595V 18:41:00: 1500/1500MHz 4.59 41% 3% 19% 0% 18% 0% 80.8°C 0.8595V 18:41:05: 1500/1500MHz 4.46 53% 1% 49% 0% 1% 0% 80.3°C 0.8595V 18:41:10: 1500/1000MHz 4.42 86% 2% 76% 0% 7% 0% 82.8°C 0.8595V 18:41:15: 1500/1500MHz 4.47 50% 2% 47% 0% 0% 0% 80.8°C 0.8595V 18:41:20: 1500/1000MHz 4.43 91% 1% 89% 0% 0% 0% 82.8°C 0.8595V 18:41:25: 1500/1000MHz 4.39 86% 2% 83% 0% 0% 0% 81.8°C 0.8595V 18:41:30: 1500/1000MHz 4.36 90% 1% 89% 0% 0% 0% 82.3°C 0.8595V 18:41:36: 1500/1000MHz 4.17 78% 5% 72% 0% 0% 0% 83.3°C 0.8595V 18:41:41: 1500/1000MHz 4.08 89% 2% 87% 0% 0% 0% 82.8°C 0.8595V 18:41:46: 1500/ 750MHz 4.07 93% 2% 90% 0% 0% 0% 85.2°C 0.8595V 18:41:51: 1500/1000MHz 3.91 68% 3% 64% 0% 0% 0% 83.3°C 0.8595V 18:41:56: 1500/1000MHz 3.83 82% 3% 78% 0% 0% 0% 82.3°C 0.8595V 18:42:13: 1500/1500MHz 4.64 79% 6% 47% 0% 24% 0% 81.3°C 0.8595V 18:42:19: 1500/1500MHz 4.35 32% 3% 11% 0% 17% 0% 79.9°C 0.8595V 18:42:24: 1500/1500MHz 4.16 50% 1% 48% 0% 0% 0% 82.3°C 0.8595V 18:42:29: 1500/1000MHz 3.99 80% 3% 68% 0% 9% 0% 82.3°C 0.8595V |
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% |
OpenSSL 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.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
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?
Thomas, you are a legend.
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?
Well, in the past I found frequency capping always related to undervoltage (or maybe I remember wrong). Anyway, it’s ThreadX here so neither documentation nor sources available.
Only random comments on the Internet like https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=147781&start=50#p972790 (which is related to the RPi 3 and 2, and the whole behavior doesn’t make that much sense any more)
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.
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.
Now, put a fan on top of the heatsink and do it again. Please. TIA!
Now dip it in liquid nitrogen and redo it again 😛
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.
Hey, I love the smell of the spinning fan in the morning.
Flat bed Raspberry Pi waffle grill and Teasmaid.
Meh, liquid helium is what real overclockers use…
I’m getting old I got the impression. We should start a new OC xprize to reach -20 Kelvin.
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.
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):
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:
Which Heatsink is used? where can i get it?
I can tell you exactly how I got the heatsink. It’s the heatsink from OpenBrix/Armbrix Zero board @ https://www.cnx-software.com/2013/02/13/armbrix-zero-cortex-a15-development-board-unboxing-pictures/
However, I got it in 2013, and the board was never sold. You should be able to get any other heatsink that’s not too big, plus thermal paste to install it. For reference. Dimensions of mine: 35x35x24mm (height)
Thank You 🙂
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
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.
No overheating, but for some reason all first runs of 7-zip were slow:
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
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.
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).