![]() I used a simple plastic chopping board as an insulator. To avoid any potential heat damage to the family heirloom piece of furniture that my test rig was now installed on. So much to the delight of my wife, I moved my Pi’s into a shaded corner of the dining room. MethodologyĪs a key measurement for these tests is temperature, I wanted to minimise the variance in ambient temperature. 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.Ī repeat of my initial test gave the results I was expecting, well worse actually, but we’ll get to that soon. 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. Running the command: vcgencmd get_throttled reported that the system had throttled. 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. 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. 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. Stressberry original used: /sys/class/thermal/thermal_zone0/temp for the temperature readings. ![]() Use vcgencmd if available for temperature and core frequency measurements.Record and plot CPU frequency for a test.This would have led to some longer than needed wait times in my long (1hr) running tests. Enable the idle times at the start and end of the test to be configurable, rather than fixed at 25% of the specified duration.Make the number of cores being actively stressed configurable.Until those changes are accepted upstream, my fork of stressberry is available on GitHub here. I needed to make some minor modifications to stressberry to meet my needs. This plotting function can plot multiple results set on a single graph and output an image. Data is collected in a yaml file which can later be passed on to the plotting function. Each test has an idle period at the start and end and it runs the standard stress utility to apply load. This tool waits for temperatures to stabilise before starting the test. In order to assist with data collection and ultimately plotting, I found the Stressberry project by Nico Schlömer. It can run on multiple cores and though not used here can be expanded to stress other components. I opted to use the standard Linux tool stress which calculates the square root of a random number to stress the CPU. I wanted to measure core CPU speed to detect for thermal throttling.I wanted to be able to vary the load, not just saturate all 4 cores.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 decided to keep it simple and focus purely on CPU load at least for now. It’s now time to look at how these different case designs perform under load conditions. Impact of various case designs on WiFi Performance of the Raspberry Pi 4.Power consumption and beta driver fixes.Temperatures of the Raspberry Pi 4 when idle in various enclosures.Initial concerns with the Raspberry Pi 4 temperature in the official Raspberry Pi 4 case. ![]() So far I’ve examined the following topics relating to the Raspberry Pi 4, especially the issues with the temperature:
0 Comments
Leave a Reply. |