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.