MichaIng
fix(dietpi-cpuinfo): give each core a chance to scale down before checking its frequency
Without this sleep, the shell script would always have caused the cpu to scale up before its current frequency was measured. There is no ideal solution to this and the delay is arbitrary, but even such small sleep value significantly reduces the impact that the script has on frequency measurements.
Compare by running cpu a few times with and without the patch. The differences will most likely be much more significant on boards with older/weaker CPUs. I've been using such modifications of the script on all my boards for a few months now. Of course those are getting overwritten by each DietPi upgrade - and each time that happens and I forget to apply my patch, I can immediately see that it isn't applied after running cpu, because the values are much higher.
Examples
Note: these are very rudimentary; there's always something else running on the system as well - the point is: to be helpful at all, cpu
command should minimize the impact the script itself has on the readings. I believe these examples show how the delay improves the situation.
Odroid C2
In a few dozen runs without the delay, the Current Freq never got below 1296 MHz (second highest possible step).
Before:
# cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | aarch64
Temperature | 37 °C / 98 °F : Cool runnings
Governor | schedutil
Current Freq Min Freq Max Freq
CPU0 | 1296 MHz 100 MHz 1536 MHz
CPU1 | 1296 MHz 100 MHz 1536 MHz
CPU2 | 1296 MHz 100 MHz 1536 MHz
CPU3 | 1536 MHz 100 MHz 1536 MHz
After:
- delay
0.05:
Current Freq Min Freq Max Freq
CPU0 | 1000 MHz 100 MHz 1536 MHz
CPU1 | 500 MHz 100 MHz 1536 MHz
CPU2 | 500 MHz 100 MHz 1536 MHz
CPU3 | 500 MHz 100 MHz 1536 MHz
- delay
0.08:
Current Freq Min Freq Max Freq
CPU0 | 500 MHz 100 MHz 1536 MHz
CPU1 | 250 MHz 100 MHz 1536 MHz
CPU2 | 250 MHz 100 MHz 1536 MHz
CPU3 | 500 MHz 100 MHz 1536 MHz
- delay
0.15:
Current Freq Min Freq Max Freq
CPU0 | 250 MHz 100 MHz 1536 MHz
CPU1 | 100 MHz 100 MHz 1536 MHz
CPU2 | 250 MHz 100 MHz 1536 MHz
CPU3 | 100 MHz 100 MHz 1536 MHz
Odroid C4
- no delay:
Current Freq Min Freq Max Freq
CPU0 | 2016 MHz 1000 MHz 2100 MHz
CPU1 | 2100 MHz 1000 MHz 2100 MHz
CPU2 | 1908 MHz 1000 MHz 2100 MHz
CPU3 | 2016 MHz 1000 MHz 2100 MHz
- delay
0.05:
Current Freq Min Freq Max Freq
CPU0 | 1608 MHz 1000 MHz 2100 MHz
CPU1 | 1404 MHz 1000 MHz 2100 MHz
CPU2 | 1000 MHz 1000 MHz 2100 MHz
CPU3 | 1000 MHz 1000 MHz 2100 MHz
Other delays yield very similar values on average.
Generally a good idea. We had a single sleep before the cores loop in earlier versions of the script. But removed it at some point, since it did not work so well. A sleep before each individual core should indeed work better (obviously does, as you show).
On systems with many cores, this can cause a significant lag 🤔. There are DietPi systems with 240 cores, i.e. 12 seconds sleep overall with 0.05s each. On such systems, it is also very unlikely that all core's frequencies are scaled up significantly for a single tiny bash script call.
So I think we'd need some negative scaling with the numbers of cores, skipping the sleep completely at some point. We could give it e.g. 0.5s overall, split across the cores, and skip if in case of 12+ cores or so, which indicates no SBC.
Can you rebase the commit onto dev and drop the master branch commits? I could do as well if needed.
