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:

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.

stressberry logo

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 vcgencmd if 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

Raspberry Pi 4

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

Raspberry Pi 4 Official Case

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

Raspberry Pi 4 - Armour/Radiator case

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

FLIRC Case

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)

Generic Aluminium case

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

Pimoroni Pibow Coupé 4 case

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)

3D Printed Case by John Sinclair. Fan disconnected.

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

Pimoroni Fan Shim

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

Raspberry Pi 4 Official Case

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

Raspberry Pi 4 - Twin Fan Armour/Radiator case

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

Generic Aluminium case with Fan

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

Pimoroni Pibow Coupé 4 with Fan Shim
Note: Heatsink pictured beneath Fan Shim was not installed in this round of testing

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)

3D Printed Case by John Sinclair. Fan 5V
Fan 5V Powered

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)

3D Printed Case by John Sinclair. Fan 3.3V
Fan 3.3V Powered

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.

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.

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

6 thoughts on “Raspberry Pi 4 Cases, Temperature and CPU Throttling Under Load

  • 4th September 2019 at 7:05 pm
    Permalink

    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!

    Reply
    • 4th September 2019 at 10:48 pm
      Permalink

      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.

      Reply
      • 5th September 2019 at 6:24 pm
        Permalink

        I’ve published updated results for the Armour case when idle. Thanks again for spotting the issue.

        Reply
        • 5th September 2019 at 9:37 pm
          Permalink

          Thanks for the update!
          45°C idling seems more in line with your on load mesures.
          Cheers!

  • 10th September 2019 at 1:56 am
    Permalink

    Can you give the exact command lines for stressberry-run and stressberry-plot?

    Reply
    • 10th September 2019 at 7:25 am
      Permalink

      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.out

      For 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.2

      For the comparison graphs, the command is similar, except you supply multiple .out files, show the legend and remove the -f and -l options since the frequency isn’t plotted on comparison graphs.

      Hope that helps. Martin

      Reply

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.