I used the PREP script to convert an Armbian Buster installation into DietPi.
But the board always runs at highest frequency even when idling, even when usage is around 2-3 %. It idles at 120 MHz only on power save governor. Threshold for CPU freq increase is set to 85%.
In fact even my older installation on Stretch had the exact same issue.
Does the /etc/defaults/cpufrequtils reflect the correct settings?
No it was not the same.
I edited it with the values as MHz:
ENABLE=true
MIN_SPEED=120
MAX_SPEED=1008
GOVERNOR=ondemand
Rebooted and I keep getting highest frequency.
I think they need to be in hz
120000
10080000
I set my governor to conservative, on demand switches from slowest to highest…conservative will step up the frequency intermittently
ENABLE=true
MIN_SPEED=120000
MAX_SPEED=10080000
GOVERNOR=conservative
Then reboot
Still the same behaviour. The system is actually reading the configuration from /DietPi/dietpi.txt.
It sets the frequencies as it should, but still…
twilight
Did you check: cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
Just to assure it really never throttles down.
And /etc/defaults/cpufrequtils is not the correct config file. On DietPi we assign CPU governor and min/max frequencies with our own preboot script. Use dietpi-config > Performance Options to adjust the values and purge cpufrequtils in case you installed it, since it is not required and its settings might override the ones from dietpi-config or the other way round.
Hi @Michalng
I have the same issue. cpu command yields this
dietpi@DietPi:~$ sudo cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | armv7l
Temperature | 34'C : 93'F (Cool runnings)
Governor | ondemand
Throttle up | 85% CPU usage
Current Freq Min Freq Max Freq
CPU0 | 1008 MHz 480 MHz 1008 MHz
CPU1 | 1008 MHz 480 MHz 1008 MHz
CPU2 | 1008 MHz 480 MHz 1008 MHz
CPU3 | 1008 MHz 480 MHz 1008 MHz
[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.
However the other command
cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
yields
dietpi@DietPi:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
480000 46421
648000 548
816000 57
960000 2
1008000 8863
So it seems like the frequency is well controlled by the governor however every time cpu command is given, we get highest freq dubbed as current freq.
Seems like either cpu command puts high load on cpu itself or maybe( very less likely) it yields wrong output.
adityakush
Both is possible indeed. Especially on low performance devices, simple commands already lead to a short-time high CPU usage, which due to DietPi default 25 ms reaction time leads to nearly immediate CPU frequency rise. This is especially true if the frequency was on lowest stage before. You could verify this by applying a higher lowest frequency for ondemand governor (dietpi-config > Performance Options), e.g. setting lower boarder to 960 MHz, then running cpu command again, or better read the frequency directly from file (much less CPU-intensive): cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Especially for the second command, the lower 960 MHz should be sufficient so that it does not raise to max 1008 MHz.
But I know from RPi, that there are cases where internal firmware overrides what the kernel governor reports. E.g. on RPi there is the “initial_turbo” config.txt setting which forces max frequency during boot for a set amount of seconds. The kernel governor starts to send freq change requests to the ARM/CPU and as well reading cur_freq and status files reports those different frequencies, but actually the ARM is on max freq the whole time, which the kernel does not/cannot know. vcgencmd on RPi allows to read out the actual frequencies. However, AFAIK on OrangePi there is no such firmware.
Hi !
The command yields out freq to be 480M Hz. You are right.
dietpi@DietPi:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
480000