Raspberry Pi 4 launched last June with a lot of buzz as it offered much better performance, more memory, and faster I/Os compared to Raspberry Pi 3 model B+.
Benchmarks confirmed the improved performance but also revealed a heatsink was necessary to ensure optimal performance under heavy loads. Some companies also launched an oversized heatsink+fan combo for the board, but it’s really over the top and absolutely not necessary unless possibly in higher room temperature (50°C?).
The Raspberry Pi Foundation also worked on improving the video to lower CPU temperature and power consumption, and a few days later released a beta version of VLI firmware that dropped the temperature by 3 to 5°C. Good effort but sadly the updated VLI firmware (used for the PCIe to USB controller) also had the side-effect of much slower USB performance. A new VLI firmware was released in September offering both a lower temperature and good performance.
The Foundation has now published a blog post detailing all the work they have done to improve the thermal performance of Raspberry Pi 4 during the four months since launch. They wrote fairly long post, so I’ll provide the main takeaways.
They stress the board with stress-ng (CPU) and glxgears (GPU):
|
1 2 3 |
sudo apt install stress-ng mesa-utils stress-ng --cpu 0 --cpu-method fft glxgears -fullscreen |
It should be noted that glxgears utility relies on OpenGL, and most Arm GPUs use OpenGL ES, so it’s quite possible several of the commands were emulated on the CPU. es2gears might have been a better choice since it uses OpenGL ES APIs only. I’m not sure how much that matters on the VideoCore V GPU in the Broadcom BCM2711 processor.
Five firmware versions have been launched since the launch of RPi 4:
- Launch firmware
- VLI firmware mentioned above
- VLI + SDRAM firmware with optimizations on how the LPDDR4 is managed without impact on performance
- VLI, SDRAM, Clocking, and Load-Step Firmware which changes how the processor increases and decreases its clock-speed in response to demand and temperature
- Current beta firmware – In testing and due for public release soon. It brings several improvements, including finer-grained control over SoC operating voltages and optimized clocking for the HDMI video state machines.
If you want to make sure your Raspberry Pi runs the latest firmware, run the following commands:
|
1 2 3 |
sudo apt update sudo apt full-upgrade sudo shutdown -r now |
And now the results with the Raspberry Pi 3 B+ as reference, and Raspberry Pi 4 with different versions of the firmware. As I understand it the boards were not fitted with a heatsink.
There’s been good progress with idle power consumption dropping from 2.89 Watts at launch to 2.10 Watts with the beta firmware, and from 7.28 Watts to 6.41 Watts under load.
The second chart shows how long it takes for the system to throttle under CPU and GPU load. Raspberry Pi 3B+ started to throttle after just 19 seconds, while Raspberry Pi 4 would do so after around 60 seconds at launch, now it takes close to 180 seconds before throttling. If the board is placed vertically however cooling improves a lot with the idle temperature dropping by 2°C, and it takes over 400 seconds before throttling.
Testing was completed with a real-life test, as opposed to the synthetic tests above, that consisted of building the Linux kernel on both Raspberry Pi 3 B+ and Raspberry Pi 4 with the latest beta firmware:
- RPi 3B+ – Total time: 5097 seconds (1h24m57s); quickly throttles to 1.2 GHz
- RPi 4B – Total time: 2660 seconds (44m20s); no throttling, runs at 1.5 GHz during compilation
It should be noted that there was no mention of room temperature as it may affect throttling quite a bit, and if your board is inside an enclosure results will vary depending on the case design, and again room temperature.
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
So in essence without a case it will be working soon?
There is no ‘essence’ available since Gareth Halfacree managed to mention the word ‘performance’ almost a dozen times but didn’t had a look a single time whether each of the various ThreadX updates had any impact on performance (ThreadX is the primary operating system controlling the hardware on any RPi). He used load generators in the most primitive way and looked only at clockspeeds. Impressive…
Well those powerful SoCs typically require a heatsink to operate. When was the last time your x86 operated without a heatsink? Maybe 486 or Pentium era before MMX?
True, but which embedded x86 board is sold without heat sink /fan ? The RPI foundation should swallow their pride (and price) and add a good heat sink standard: nobody is unfailable.
>True, but which embedded x86 board is sold without heat sink /fan ?
Galileo doesn’t have a heat sink or fan.
Usually if you need a heatsink or fan the manufacturer lets you know this fact and most importantly also provides a mounting concept.
My UK101 (Ohio Superboard2 clone) didn’t have a heatsink on the CPU, nor did my Commodore Amiga 500. I recall how a key selling point of personal computers was they were quiet and didn’t have the huge cooling requirements of mainframes.
Ok let’s test. Baseline is latest ‘Raspbian Lite’ image. I’m running sbc-bench 0.6.9 with ondemand governor (defaults): ThreadX version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (Sep 24 2019) Memory performance: memcpy: 2548.6 MB/s memset: 3443.1 MB/s (0.5%) 7-zip total scores (3 consecutive runs): 5753,5746,5747 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 62547.58k 76713.54k 83105.79k 84648.96k 85194.07k 85235.03k aes-128-cbc 62585.24k 76661.18k 83106.22k 84593.66k 84934.66k 85120.34k aes-192-cbc 56282.45k 67343.59k 72109.91k 73362.77k 73640.62k 73684.31k aes-192-cbc 56290.66k 67505.15k 71985.32k 73363.11k 73728.00k 73564.16k aes-256-cbc 51013.75k 60051.84k 63554.22k 64586.41k 64916.14k 64940.71k aes-256-cbc 50872.67k 60064.87k 63684.86k 64568.32k 64877.91k 64858.79k Full results uploaded to… Read more »
Now let’s check the influence of the VLI USB host adapter firmware. After unpacking vl805_update_0137ab.zip and applying the firmware update, followed by a cold boot repeating the iozone tests: ondemand random random kB reclen write rewrite read reread read write 102400 4 10617 12985 15985 15985 13113 12903 102400 16 38549 47744 54443 54694 45171 47223 102400 512 199253 201459 199932 201603 197200 203022 102400 1024 233335 235683 247508 249198 244401 237123 102400 16384 293854 295982 335363 339289 340120 281198 1024000 16384 296134 294716 347073 346733 performance random random kB reclen write rewrite read reread read write 102400 4 13205… Read more »
So another load of fud… It almost sounded too good to be true, from just skimming over.
Now just jerry missing and some super logical jamesh bs…
Now testing with latest ‘firmware’ update applied (using rpi-update, an apt full-upgrade didn’t do the trick). ThreadX version is aabb1fb5c19d80db268aeccd67b9f4e0f3d48a2a from Nov 29 2019: Memory performance: memcpy: 2731.5 MB/s memset: 3447.9 MB/s (0.5%) 7-zip total scores (3 consecutive runs): 5286,5354,5535 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 62544.21k 76674.54k 83071.06k 84506.62k 85251.41k 85180.42k aes-128-cbc 62584.02k 76643.37k 83107.50k 84629.50k 85073.92k 85256.87k aes-192-cbc 56292.51k 67257.22k 72109.65k 73255.25k 73613.31k 73673.39k aes-192-cbc 56294.33k 67505.58k 71986.60k 73255.59k 73722.54k 73580.54k aes-256-cbc 51018.45k 59990.51k 63578.03k 64573.44k 64921.60k 64935.25k aes-256-cbc 50873.84k 60002.65k 63664.64k 64478.21k 64790.53k 64880.64k Full results uploaded… Read more »
Interesting. Thanks for explaining.
Device available for 35-55$, additional heatsink/cooling fan/heatpipe solution 2.7$-21.99$/~£6.72/21.99-29.99$.
Even cheap devices won’t be limited through IOPS or bandwidth in a (few) couple of years on user profile browsing or multimedia tasks. Avoiding hot pcb keeps being a challenge, maybe.
What is our responsibility for power savings (on server types and consumer side load balancing: AI optimization)? That might be a bigger question.
Sorry, but that’s just hilarious that physics works like this
https://i.imgur.com/snmRuWK.png
Most important for me is that the latest beta firmware adds HDMI power off for those of us using a pi4 as a desktop.
With the heat control and standing it vertical, you are most of the way to building a talkie toaster.
Preliminary conclusion from my side (as someone who is only interested in ‘light server’ use cases): Since I need storage performance I reverted the USB controller’s firmware back to the initial version vl805_fw_013701. I use the latest beta ThreadX release (called firmware in RPi land) and opted for a slight ‘overclock’ to 1750 MHz: over_voltage=2 arm_freq=1750 12 over_voltage=2arm_freq=1750 Then tested USB3 storage performance again which looks pretty good (especially random IOPS are good again — and this even with ondemand cpufreq governor which helps reducing idle temperatures and consumption): ondemand random random kB reclen write rewrite read reread read write… Read more »
ThreadX is a binary blob owned by Microsoft and Broadcom, so when do they release it under an open source license?
When? Never.
And Microsoft is not involved here: https://www.raspberrypi.org/forums/viewtopic.php?p=1460642#p1460642
Express Logic got bought out by Microsoft for an undisclosed sum of money at the beginning of this year, tkaiser…
https://rtos.com/solutions/threadx/real-time-operating-system/
Now, I’d believe that Broadcom doesn’t own it, but is paying royalties to the owner of ThreadX there.
There’s a distinct difference with having a Source License and not paying Microsoft. The presumption is that there is no code concerns, which is a bit different than mine and many others’- which is I’m paying Microsoft money per each Pi, period. Even with a source license, there’s typically a per-unit cost that you still pay the vendor on the royalties side of things. With GPL, it’s merely compliance as they remuneration. In this case, I’d rather not be beholden to them…or to someone paying money to maintain the fork, which is what this is.
>so when do they release it under an open source license?
If they intended to ever release the code why would they have used an RTOS that they can only ship as a compiled binary?
Because they never intended to Open Source anything at the times these cores were designed. They were intended for set-top and varying Android original task sets for business customers. They had a bit of a change of heart over time since that time. Having said this, I’d think they’d re-think the RTOS and re-work the VC-IV/VI firmware to be something comparable to the current and use Zephyr, FreeRTOS, etc. there instead. Definitely lower licensing costs (It costs Broadcom per unit for this…)
Releasing the source might actually endanger millions of existing installations if static analysis tools or security experts found bugs in the code. It’s always the case when commercial code has been leaked. RPi foundation does not want to increase the risk of existing user base with shortsighted opportunism. Future RPi versions might run a completely free firmware, but it needs to be started from scratch like the VC4 GL driver.
“It should be noted that glxgears utility relies on OpenGL, and most Arm GPUs use OpenGL ES, so it’s quite possible several of the commands were emulated on the CPU. ”
The GPU is capable of OpenGL 2.1 and OpenGLES 3.2.
We’re talking about glxgears here, it’s not exactly Crysis. Even if there were emulated OpenGL calls it would have been unlikely to hit them.
How about a passive heatsink…?
That is what they tried to do with the heat spreader top.