Raspberry Pi 4 Cases, Temperature and CPU Throttling Under Load
So far I’ve examined the following topics relating to the Raspberry Pi 4, especially the issues with the temperature:
- Initial concerns with the Raspberry Pi 4 temperature in the official Raspberry Pi 4 case.
- Temperatures of the Raspberry Pi 4 when idle in various enclosures.
- Power consumption and beta driver fixes.
- Impact of various case designs on WiFi Performance of the Raspberry Pi 4
It’s now time to look at how these different case designs perform under load conditions. I decided to keep it simple and focus purely on CPU load at least for now. Setting the following requirements:
- I wanted a test that I could run for a long duration, to test ensure metal cases didn’t reach a heat saturation point.
- I wanted to be able to vary the load, not just saturate all 4 cores.
- I wanted to measure core CPU speed to detect for thermal throttling.
TLDR; Jump to the conclusion section.
Tools
I opted to use the standard Linux tool stress which calculates the square root of a random number to stress the CPU. It can run on multiple cores and though not used here can be expanded to stress other components.
In order to assist with data collection and ultimately plotting, I found the Stressberry project by Nico Schlömer. This tool waits for temperatures to stabilise before starting the test. Each test has an idle period at the start and end and it runs the standard stress utility to apply load. Data is collected in a yaml file which can later be passed on to the plotting function. This plotting function can plot multiple results set on a single graph and output an image.
Changes to Stressberry
I needed to make some minor modifications to stressberry to meet my needs. Until those changes are accepted upstream, my fork of stressberry is available on GitHub here. The changes in outline are:
- Make the number of cores being actively stressed configurable.
- Enable the idle times at the start and end of the test to be configurable, rather than fixed at 25% of the specified duration. This would have led to some longer than needed wait times in my long (1hr) running tests.
- Record and plot CPU frequency for a test.
- Use
vcgencmdif available for temperature and core frequency measurements. - plus several other minor tweaks.
CPU Frequency Measurement
Stressberry original used: /sys/class/thermal/thermal_zone0/temp for the temperature readings. When looking to measure core frequency, I elected to read: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq as this seemed the logical choice. However, after performing the first test run where I knew the CPU temperature was sufficiently high that the Raspberry Pi 4 would have throttled, the measurements didn’t show this. They showed the processor core starting at 600MHz (idle min frequency) jumping to 1500MHz as soon as the load was applied and remaining there till the end of the test.
Running the command: vcgencmd get_throttled reported that the system had throttled. Odd.
Reading various forum posts I soon discovered that on the Raspberry Pi, the only reliable source of core frequency comes from vcgencmd measure_clock arm.
So with this knowledge, I set about and replaced my initial approach using files with calls to vcgencmd measure_temp and vcgencmd measure_clock arm, for temperature and core frequency measurements respectively.
A repeat of my initial test gave the results I was expecting, well worse actually, but we’ll get to that soon.
Methodology
As a key measurement for these tests is temperature, I wanted to minimise the variance in ambient temperature. So much to the delight of my wife, I moved my Pi’s into a shaded corner of the dining room. To avoid any potential heat damage to the family heirloom piece of furniture that my test rig was now installed on. I used a simple plastic chopping board as an insulator. For ambient temperature measurement I setup a 433MHz temperature/humidity sensor and a ZigBee temperature/humidity, both logging data to my HomeAssistant setup.
Tests were conducted on two Raspberry Pi4, testing different enclosure setups in parallel. Stressberry was configured to use a 5 minute idle time either side of a 60 minute stress test. Note that stressberry won’t start until the temperature has stabilised for a minute.
Tests were run against 1, 2, 3 and then finally all 4 cores. Between tests, an air duster was occasionally used to bring the temperatures down ahead of the attempting the next test.
These are all obviously stress tests, most general usage, even as a desktop replacement, would be unlikely to have all 4 cores running at 100% for hours on end. Instead, usage is likely to be more bursty in nature, allowing time between the bursts for things to cool a little. The single-core stress may be more representative of a device under a more normal load.
Results: Passively Cooled
RPi4 Bare Board
1 Core | 69°C 2 Cores | 76°C 3 Cores | 82°C | 1000MHz 4 Cores | 83°C | 1000MHz
The bare Raspberry Pi 4 board without any additional heat sinks or fans is able to handle the 1 and 2 core stress tests without any throttling. The 3 and 4 core tests see temperatures increasing over 80°C and the Pi trigging its thermal throttling. This reduces the core clock speed from 1500MHz down to 1000MHz, as this is on the edge of the throttling window this drop in clock speed is sufficient to allow the speed to be boosted back up again, increasing heat, so throttling again. Creating an oscillation in core clock speed around the two points.
RPi4 Official Case
1 Core | 83°C | 1000MHz 2 Cores | 86°C | 600MHz 3 Cores | 87°C | 500MHz 4 Cores | 88°C | 428MHz
As we’ve seen from my earliest tests with Raspberry Pi 4 official case which has problems even sitting idle. Stress testing even a single-core sees thermal throttling down to 1000MHz as temperature increases.
The 2 core stress sees the clock speed step down and oscillating mostly between 1000MHz and 750MHz (50% of the original core speed), with several further drops to 600MHz.
The 3 core stress shows the clock mainly between 600MHz and 750Mhz with several drops to 500MHz
The heaviest 4 core stress sees the core clock mainly running between 750Mhz and 500MHz with a couple of drops as low as 428MHz as the temperatures hit 88°C.
In its stock form, this case is completely unsuitable for the current heat loads of the Raspberry Pi 4. Leave the lid off, cut some holes, install a fan. Do something, don’t leave your Pi 4 to cook in the official oven, case.
Armour Aluminium Radiator
1 Core | 51°C 2 Cores | 56°C 3 Cores | 60°C 4 Cores | 63°C
This aluminium radiator/armour case design performed exceptionally well in all tests. Due to the huge surface area of metal which is able to soak up and radiate the heat aware from the Raspberry Pi 4 processor and memory chip.
Even with all 4 cores under stress for an hour, the core temperature only hit 63°C, the lowest of all the passively cooled cases tested so far. However as noted in the WiFi testing, this enclosure design does impact WiFi signal strength, so if this is critical to you, you may wish to look at the 2nd best passively cooled case, the FLIRC.
FLIRC
1 Core | 55°C 2 Cores | 62°C 3 Cores | 68°C 4 Cores | 73°C
The FLIRC case once again uses a large surface area of metal to provide a large heatsink combined with a Raspberry Pi 4 enclosure. The design of the FLIRC is certainly a step above the other designs.
Under increasing load, the FLIRC is able to cope well, with the temperature peaking at 73°C and no signs of throttling. During the tests, the ambient temperature was 22-23°C. If the ambient temperature was heading towards 30°C, then there would be a risk of throttling occurring in the heavier load tests.
Whilst the FLIRC case comes second in terms of thermal performance for a passive design. It should be noted it performed surprisingly well in the WiFi tests.
Generic Aluminium (with heatsinks)
1 Core | 72°C 2 Cores | 80°C 3 Cores | 84°C | 1000MHz 4 Cores | 85°C | 750MHz
This generic aluminium case runs 2-3°C hotter than the Raspberry Pi 4 bare board. It does have heatsinks on a number of the components, increasing the surface area for cooling, and with ventilation making it significantly outperform the official case. This small difference in temperature compared to the bare board, allows the 1 and 2 core tests to successfully avoid throttling, though at 80°C the 2 core stress only just missed this.
The 3 core stress sees throttling occurring throughout the test, oscillating between 1500MHz and 1000MHz.
The 4 core test sees running at 1000MHz for most of the test, with drops to 705MHz on a couple of occasions.
This case design doesn’t offer the protection, cooling performance or aesthetic design quality of the FLIRC case. However, it would be possible to use some HATs with this case, but beyond that, I see little appeal in this middle of the road case.
Pimoroni Pibow Coupé 4
1 Core | 75°C 2 Cores | 83°C | 1000MHz 3 Cores | 84°C | 1000MHz 4 Cores | 86°C | 600MHz
The 1 core stress, sees the temperature notably higher than the bare Raspberry Pi 4 board but manages to avoid throttling.
The 2 and 3 core stress results show frequent throttling, with the core running between 1500MHz and 1000MHz.
The 4 core stress sees temperatures rise to 86°C, with the results of the clock speed running between 1000MHz and 750MHz with several drops to 600MHz.
The Pimoroni Pibow Coupé 4 case only offers marginally more protection than a bare board, but the wrapping the board in layers of plastic impacts performance in heavy load scenarios. It does offer space carved out for the Fan Shim (tested below) and for a large 40x30x5mm heatsink (untested). In the original form, it maintains full easy access GPIO header allowing HATs to continue to be used, though likely with a negative impact to cooling.
John Sinclair 3D Printed Pi 4 Case (with Heatsink | Fan off)
1 Core | 70°C 2 Cores | 85°C | 750MHz 3 Cores | 86°C | 600MHz 4 Cores | 87°C | 500MHZ
With the 40mm fan disconnected, the single core stress the CPU temperature peaks at 70°C.
With 2 cores being stressed peak temperature rises to 85°C leading to throttling to so that it runs between 1500MHz and 1000MHz for most of the test with brief drops as low as 750MHz.
With 3 cores being stressed, CPU temperature hits 86°C with the test running mostly between 1000MHz and 750MHZ, with brief drops to 600MHz
The full load 4 core stress has a peak CPU temperature of 87°C with the test running at between 1000MHz and 600MHz with a brief drop to 500MHz.
These temperatures are higher than the generic aluminium case, showing that the metal of the other case helps to radiate some of the heat.
Results: Actively Cooled
With active cooling installed all the systems under test were able to avoid throttling (with the exception of a small drop to 1000MHz during the 4 core tests with the Official Raspberry Pi 4 case with the Fan Shim installed).
The temperature difference between passive cooling vs active cooling varies widely depending on the case design.
RPi4 Bare Board with Pimoroni Fan Shim
1 Core | 41°C 2 Cores | 45°C 3 Cores | 48°C 4 Cores | 51°C
With the installation of the Pimoroni Fan Shim throttling under all levels of stress load is avoided.
Temperatures with the fan constantly running are 28°C to 32°C lower. This is a substantial drop, providing significant headroom for an increase in ambient temperatures whilst still avoiding CPU throttling.
RPi Official Case with Fan Shim
1 Core | 64°C 2 Cores | 71°C 3 Cores | 75°C 4 Cores | 82°C | 1000MHz
Whilst there is one brief measurement where throttling occurred, on the whole, the Fan Shim installed within the Official Raspberry Pi 4 case lowered temperatures by 19°C for 1 core, 15°C for 2 cores, 12°C for 3 core, but only 6°C during the heaviest 4 core stress.
With a small increase in ambient temperature, the 4 core stress could easily enter more significant periods of throttling.
The design of the case doesn’t allow for much airflow, so the Fan Shim struggles to push air through the case. I suspect a small number of ventilation holes, would make a significant difference to cooling performance.
Armour Twin Fan Aluminium Radiator
1 Cores | 45°C 2 Cores | 50°C 3 Cores | 54°C 4 Cores | 57°C
Like the version without a fan, this twin fan version avoids any throttling occurring by a significant margin. The benefits of the twin fan version are however minimal with just a 6°C decrease. Leaving the system running several degrees hotter than the bare board Raspberry Pi 4.
The relatively poor performance, with the addition of active cooling, is not really a surprise as the fans are directly mounted to the metal, with one face directly in front of a solid piece of metal, providing a very limited airflow over the metal fins.
The current design of this case doesn’t offer any real benefit given the additional noise, additional power consumption and impact on some GPIO header pin access. I’m sure this case design could be improved by raising the fans, or drilling holes in the sold face of metal the fans are resting against. Though no modifications of the design have been tested.
Generic Aluminium with Fan
1 Core | 47°C 2 Cores | 51°C 3 Cores | 54°C 4 Cores | 58°C
The addition of a 5V 30mm fan to the generic aluminium case provides some gains in cooling performance. Reducing temperatures between 25-30°C. These cooling gains come at a cost, the fan included is incredibly loud in both push and pull configurations. Though the fan blades are protected by the metal enclosure. A different/better fan may be quieter and make it a more feasible offering.
Pimoroni Pibow Coupé 4 with Fan Shim
1 Core | 43°C 2 Cores | 48°C 3 Cores | 53°C 4 Cores | 56°C
The addition of the Fan Shim to the Pibow Coupé case sees temperatures decrease by 30°C to 35°C. Placing it second to the bare Pi board in terms of thermal performance, but running just a few degrees hotter.
The real advantage of the Fan Shim is the ability to install additional software and make the fan turn on and off at a temperature threshold. But as already noted the Fan Shim uses a number of GPIO pins to provide this function, not just a simple 5V or 3V supply.
John Sinclair 3D Printed Pi 4 Case (with Heatsink | Fan 5V)
1 Core | 41°C 2 Cores | 45°C 3 Cores | 46°C 4 Cores | 48°C
This 3D Printed case comes with a 40mm fan installed. Running at 5V off the GPIO header it’s a little noisy, quieter than the loud fan included in the Generic Aluminium case, but not a quiet as the Pimoroni Fan Shim. I wonder if the Noctua 40mm fan would be quieter. Luckily as the fan wires are individual connections we can also test using the 3.3V as well as 5V, in order to run the fan a little slower.
With the fan running at 5V, there isn’t any CPU throttling in any of the tests. With the CPU temperature peaking at 41°C, 45°C, 46°C and 48°C for the 1, 2, 3 and 4 core tests respectively.
John Sinclair 3D Printed Pi 4 Case (with Heatsink | Fan 3.3V)
1 Core | 42°C 2 Cores | 44°C 3 Cores | 49°C 4 Cores | 53°C
Running the 40mm fan at 3.3Volts instead of 5V, causes the fan to run more slowly and as a result noticeably quieter.
Like running at 5V, this test at 3.3V doesn’t see any CPU throttling.
During the 1 and 2 core stress tests, the CPU temperature remains about the same as the 5V scenario. Only during the 3 and 4 core stress tests does the additional benefit for the faster running 5V become apparent.
During the 3 core stress, the 3.3V test is 3°C degrees worse than at 5V, 49°C vs 46°C.
During the 4 core stress, the 3.3V test is 5°C degrees worse than at 5V, 53°C vs 48°C.
Conclusion/Comparison
Passively Cooled Temperatures
I’m a strong proponent of silent, passive cooling solutions for my Raspberry Pi’s. There are two standout cases in this category. The Armour/Radiator design offers the best cooling performance. The FLIRC design offers a more elegant fully enclosed solution that provides good cooling performance and significantly better WiFi performance per my previous testing.
Click to enlarge the graphs below, which show the relative thermal performance.
Passive – Single Core Tests Passive – 4 Core Tests
Actively Cooled Temperatures
When looking at the active cooling solutions, there is one stand out result, but for the wrong reason. The Official Pi 4 case is simply terrible, those wanting to use that design should seek to modify that case to provide some much need ventilation.
At full load, the John Sinclair 3D printed case with the 40mm Fan running at 5 Volts manages to outperform even the bare board with the Fan Shim. The volume of air through the case is the most effective at keeping temperatures low.
The twin fan Armour/Radiator case doesn’t offer any worthwhile benefit over its purely passively cooled version.
The cheap 30mm fan on the generic aluminium case is intolerably noisy, I’d recommend everyone avoid that one.
The remaining actively cooled enclosures are very similar in terms of thermal performance, such that other characteristics of their design should drive user choice.
Active – Single Core Tests Active – 4 Core Tests
Parts Tested
Note, Amazon UK links are affiliate links, meaning I may make a small amount of money in return from you following the link and buying the product
- Raspberry Pi 4 (Amazon) (Pimoroni)
- Enclosures:
- Raspberry Pi 4 Official case (Amazon) (Pimoroni) (The Pi Hut)
- Armour aluminium radiator (Amazon) (Pimoroni) (ebay) (The Pi Hut)
- Armour twin fan aluminium radiator (Amazon) (ebay) (The Pi Hut)
- FLIRC Raspberry Pi 4 Case (Amazon) (The Pi Hut)
- Generic aluminium case with heatsinks (Amazon-UK)
- Generic aluminium case with heatsinks and fan (Amazon-UK)
- Pimorni Pibow Coupé 4 (Pimorni)
- John Sinclair 3D Printed (Design: Thingiverse) (eBay)
- Pimorni Fan Shim (Amazon) (Pimorni)
Hello! Thanks for your extensive study!
Just a remark on the passive “Armor aluminium radiator”. (Which I use and love)
In your previous mesures for idle temperatures, it was at 63°C.
But it’s higher than all the temps you found under load.
Even with 4 cores under stress for an hour…
Something fishy happenend during your idle mesure? Missing the thermal pads or something?
Do you plan to do a new bench with overclocking?
My pi4 is doing great with the passive armor aluminium radiator at 2 Ghz (cpu), 600 (gpu), overvoltage 5
Anyway, thanks for the time you already spent on this!
Good catch. I’ll re-run the idle test with the Armour case now and see what happens.
I’ve no plans to look at overclocking at the moment. However, if there are a number of requests I’d certainly look into it.
I’ve published updated results for the Armour case when idle. Thanks again for spotting the issue.
Thanks for the update!
45°C idling seems more in line with your on load mesures.
Cheers!
Can you give the exact command lines for stressberry-run and stressberry-plot?
You’ll need the latest version of stressberry where my changes have been integrated. Or for even more enhancements my own branch now includes a way to measure ambient temperatures and then produce a Delta-T value, as a spin off from that branch I’ve also just added some helper scripts I’m now using to increase the efficiency of running blocks of tests and plotting all the data I need. The helper scripts will let you see the commands I’m using.
By in simple terms, running a test (
-d) 1hr stress, (-i) 5 minute idle periods, (-c) 1 core:/home/pi/.local/bin/stressberry-run -n "test name" -d 3600 -i 300 -c 1 test_name.outFor plotting individual graphs, (
-d) image DPI, (-f) with frequency, (-l) frequency axis limits, (-t) temperature axis limits, (--hide-legend) don’t show legend, (--not-transparent) make image background opaque, (–line-width) thinner graph line:MPLBACKEND=Agg /home/pi/.local/bin/stressberry-plot test_name.out -f -d 300 -f -l 400 1600 -t 30 90 -o test_name.png --hide-legend --not-transparent --line-width 0.2For the comparison graphs, the command is similar, except you supply multiple .out files, show the legend and remove the
-fand-loptions since the frequency isn’t plotted on comparison graphs.Hope that helps. Martin
We use a range of pi’s as part of a compute cluster to test some software. Our tests involve building the software off the SD card and then running a range of test files through it from a USB card. Clearly, a different load than you’ve been testing, but you’d imagine that these tests would be “less stressful” than yours.
In particular, I have a Raspberry pi3b+ in a passively cooled Armour case. One of the other machines is a plain pi3b in a “normal” case with heatsink + fan.
Despite the armour case the pi3b+ thermal throttles under load, and so often performs worse than the pi3b does.
Given that (AIUI) the pi4 produces more heat than the pi3b+ does, it seems likely to me that if I start to use pi4’s in the cluster, they are going to throttle even worse. It makes me wonder why I’m seeing throttling under load with the passive Armour case, and you aren’t.
I had considered moving to the actively cooled armour case for the pi4’s, but it seems from your results that I’d be better off with the active John Sinclair case. This is a shame, in a way, because you’d really think that the huge size of the heatsink in the active armour case should be a win.
Thanks immensely for the tests you’ve done already – they are really useful.
If there was one more test result I’d love to see, it’d be to retest the active armour case with the fans raised a couple of millimeters (unscrew them, put a fragment of elastic band under each corner, screw them down again). You’d hope that should be enough to allow much saner airflow, and for the fans to actually be some benefit…
Hi Robin,
My immediate reaction to why you might see different throttling behaviour between two RPi3 B+ would be to confirm if they are running the same firmware. There was change which reduced the soft throttle from 70°C to 60°C – see: https://github.com/raspberrypi/firmware/issues/1014#issuecomment-401599394 This can be overridden from the config file if needed. So I’d recommend you check the firmware. Of course, you could also measure the temperature to confirm what temperature it is reaching. Other things to check is ensuring the thermal pad is in place, I originally had some bad idle temp results with the armour case when I suspect there was an issue with the pad, i.e. I may have forgotten to install it. Then there is the ambient temperature to consider, if you have a cluster of Pi’s is there a risk they are heating each other up?
However, I think anything with a Fan is likely to outperform a passively cooled case, as we’ve seen in the Pi4 testing.
Again thinking about your cluster, it might be better to build a configuration where you can cool the entire cluster from a larger fan to keep the noise down and avoid the need for individual cases for the Pi’s. Things like:
As for spacing off the fans on the twin fan Armour case. I’ll add that to my to-do list and see what happens.
It’s a pi3b+ in a passive armour case vs a pi3b with a heatsink in a fan case (i.e. not two pi3b+’s).
I’m not surprised that one throttles and the other doesn’t. I’m surprised that you found that the passive case was enough to avoid throttling with the pi4. Given the larger thermal output of the pi4, I’d have expected it to have throttled too.
The thermal pads are certainly in place. And as for one pi heating the other up… one is on the desk next to me in the UK, the other in LA (and others in SF), so I *think* they are far enough apart 🙂
I’ve just ordered a pair of pi cooling fans off amazon – I’ll try sticking one of them to the top of the passive armour case – hopefully, that should make a significant difference.
We’re planning to expand the cluster with 10 pi4’s in the next few weeks. Those will all go into a server room, so noise isn’t an issue. If I can find a neat ‘mini rack’ with a decent fan, that is certainly an option, though the desire for better cooling overrides space in this instance.
Thanks again!
For those interested… I just spent 4.99 on Amazon and purchased 2 “pi-fans” (3×3 cm fans with flying leads).
With the pi3b+ in the passive armour case, it peaks at 60.1 C running our tests. Running the same thing again with one fan on top, it peaks at 55.8 C. Running again with both fans on top, 53.7 C. (All fans connected to 5V, and attached by gorilla glue).
I’d imagine that this should give better cooling than the normal ‘active’ armour case as there is room for decent airflow around the fans.
With the fans in place, the pi3b+ is now the fastest board in our cluster (until the pi 4’s arrive at least!) The fans are as close to silent as I can imagine, so I’m very pleased. I think this emphasises the fact that decent cooling is a must if you want performance.
We could offer colorful Pi 4 cases
As time passes there are, as you’d expect many more cases for the Raspberry Pi coming on to the market. Most are aware of the thermal load of the Pi 4 and the designs are being tailored for that. There are now various colours of Armour radiator case now available and the Pimoroni cases have always been available in very colourful versions.
Nice work ! How can I do to run stressberry, but with another test, by example cpuburn53 ? thks
If you wanted to use CPUburn instead of stress, just download the source for stressberry, modify stressberry/main.py to run cpuburn-a53 instead. However since CPUBurn doesn’t have a timeout option, nor can you define the number of cores to target it would be a full load test only. Which may be what you want. If you wanted to add a time limit you’d want to keep track of duration in the main.py and kill cpuburn once it had run for as long as you specified. If modifying stressberry isn’t something you’d be comfortable doing, let me know and I’ll see if I can quickly come up with something.
Adrian, Actually I’ve just implemented the ability in a branch of stressberry. If you want to try it out, get and install my latest version in the cpuburn branch: https://github.com/shortbloke/stressberry/tree/cpuburn
run
stressberry-runwith a--cpuburnargument and it will run cpuburn instead of stress. Note you’ll need to ensure cpuburn-a53 is installed and you’ve created a symlink or similar so that cpuburn runs the correct version. Of you can modify main.py with the location/filename you want.If you need help installing it, just ask.
What about testing CooliPi 4B against the crowd?
Happy to test products I can get my hands on. Though the review are done in my spare time and I have a number of projects on the go and reviews to complete.
Hello Martin,
Many of the passive cooling cases put a piece of aluminium on the Pi4 SoC to cool down.
Flirc does that in a “half way” using “air circulation” inside. So your measurements indicate about 70°C for Flirc and about 62° for Armour. But what is with “3M 9448A” which is often delivered as a “thermal pad”. Did you use that? Or heat-conductive paste?
In my tests on https://progpi.de/cpu-stresstestverfahren/ I used a 0.5 mm thick piece of copper between CPU and the heatsink of the case. My 60 min. measurements
( https://progpi.de/wp-content/uploads/2019/12/plotrun_JoyIT_ProgPi.jpg )
give values <= 55°C – using an additonal 16*20 cm copper plate under the aluminium case (RB-AlucaseP4+08). And I got about further 3°C down increasing the thickness of the copper on the SoC up to 0.7 mm (maybe with a little bit more pressure on the screws of the case, which was not possible with 0.5 mm due to the case construction).
Blessed Christmas
Harald Schmidt
Hi Harald, my testing used the thermal pads supplied with each case I tested. Please keep in mind results in this post are from September 2019, since then there have been several OS/firmware updates released which have reduced power consumption and thus heat. In addition, if tests have not accounted for changes in ambient temperature, this further makes comparisons between different peoples test results very difficult.
However, your post showing the modifications and benefits with the JoyIt aluminium case are certainly interesting.
We had to design and machine our own aluminum cooler to keep the Pi 4 heating under control. First we bought a cheap cooler from Ali but that wasn’t enough, also we were afraid to buy the one with double ventilators because who knows how long it would last . We are using the Raspberry to one of our product a refueling authorization system and during summer it would melt down without our passive cooler. Maybe we have to make a bigger cooler now because of global warming.
Hi how can your method be uses under Hassos
I’m not sure what you mean. Please can you clarify what exactly you are trying/wanting to do?
Hi martin,
Thanks for your response.
I wanted to know how to use stress, stressbery-plot etc in Home assistant OS.
If you wanted to run those tools within Home Assistant, you’d need to create your own add-on which provided these tools. I’m not sure why you’d want to run these tools within HA, it’s not really designed for that. You would be better having a second SD card with Raspbian and these tools installed. If you want to use your Home Assistant device for different things, then running HA in a venv on Raspbian would make more sense, however, the HA team are deprecating the running HA on a generic Linux system, per: https://www.home-assistant.io/blog/2020/05/09/deprecating-home-assistant-supervised-on-generic-linux/ so that’s not a route you’d want to start exploring now.
The easiest way forward to be able to run tests, is a second SD card or better still a second Pi for testing with, leaving your HA happily running elsewhere.
Thanks martin.
Sorry for the delay on my part.
Martin, it’d be interesting to see the effects of orientation, particular for the passive cases.
From https://www.raspberrypi.org/blog/thermal-testing-raspberry-pi-4/ :
“While running the latest firmware will result in considerable power draw and heat management improvements, there’s a trick to unlock even greater gains: adjusting the orientation of Raspberry Pi. For this test, Raspberry Pi 4 with the beta firmware installed was stood upright with the GPIO header at the bottom and the power and HDMI ports at the top.”
Hi Chris, a bare Pi allows for greater natural airflow and convection when placed on its side, compared to the relatively restricted airflow to the underside when placed flat on a surface. Once a Pi is enclosed in plastic cases the plastic acts an insulator and obstructs natural airflow such that I doubt the orientation will have any meaningful impact. Certainly in the very first evaluation of the official Pi4 case, changing the orientation had no measurable benefit, though I don’t have detailed test results captured for that. Metal passive cases which act as large heatsinks to conduct heat away may benefit from different orientations to lower their temperatures further, but as they don’t suffer thermal throttling whilst laying flat, there isn’t a performance benefit in doing so.
Thanks Martin
Hi Martin,
Thank you very much for that, that’s very helpful!
I have a question though. Would the Pi4 with the Armour Aluminium Radiator fit inside the official case? The FLIRC?
What would the temps be then?
Thank you.
Hi,
1) Will the Armour case fit inside the Offical Pi case? – No it doesn’t fit as the metal base makes it too tall. Removing the metal base and it fits in the space, but the top cover can’t be attached as the mounting lugs/clips at the rear of the case can’t engage as the metal gets in the way. Also, it’s a terrible idea. The Armour cases rely on convection currents of air to cool the heatsink, placed inside a case without any airflow will significantly impact the performance.
2) Will the Armour case fit inside the FLIRC case? – No it doesn’t fit, the FLIRC case has a metal extrusion that comes down from the top and interfaces with the Pi SoC to conduct heat away.
You seem to be looking to try and combine cases to get something better, I doubt this would be all that successful as the benefits of a given case may be lost if mixed within another solution. You might be able to combine the base from the Armour case with the ICE Tower cooler, though I’ve not tested it.
Maybe if you can clarify your goal I can offer some advice?
Thank you for your answer.
Actually no, I wasn’t trying to combine the benefits of both cases ; I expected the thermal to be worse of course, just wanted to know by how much. It was only from an aesthetic standpoint…
Regarding the FLIRC, yes, of course… Didn’t account for the heatsink/thermal pad on the SoC, that was dumb…
I guess I’ll stick to the Armour “case” alone then.