fix(dietpi-cpuinfo): give each core a chance to scale down before checking its frequency

[rozcietrzewiacz]

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.

[rozcietrzewiacz]

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.

[MichaIng]

Suggested change

	sleep 0.05 # Necessary to give the scheduler a chance to scale down the core in (quite likely) case this script has already caused it to ramp up the frequency
	G_SLEEP 0.05 # Necessary to give the scheduler a chance to scale down the core in (quite likely) case this script has already caused it to ramp up the frequency

/bin/sleep is an external executable, expensive to call. We have a G_SLEEP function which provides the functionality very cheaply with pure shell features. This also reduces the processing for the sleep call itself significantly.

[MichaIng]

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.