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.