Dietpi: RPi | Static CPU governor not effective after initial turbo/throttling

Created on 17 Aug 2020 · 29Comments · Source: MichaIng/DietPi

Creating a bug report/issue

Required Information

DietPi version
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=31
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
Distro version | 10.4
Kernel version | Linux BoincPi01 5.4.51-v7+ #1327 SMP Thu Jul 23 10:58:46 BST 2020 armv7l GNU/Linux
SBC model | RPi2 / RPi4 (above versions are from RPi2 Model)
Power supply used | (EG: 5V 1A RAVpower)
SDcard used | (EG: SanDisk ultra)

Additional Information (if applicable)

Can this issue be replicated on a fresh installation of DietPi?
Tested and replicated on RPi2 and RPi4.

Steps to reproduce

set CPU Governor to Performance
vcgencmd measure_clock arm (should display the correct clock as set)
reboot
vcgencmd measure_clock arm (displays idle CPU clock)
to make it "work" again just change CPU Governor and everything is working as intended

I've tested this with Ondemand, Conservative and Performance with different results on RPi2&4. On RPi2 no mode seems to work even if i switch back to Ondemand. My guess is that Powersave mode is affected too but no problem since u want the Idle CPU clock. On RPi4 just Performance Governor is not working correctly after reboot.

If u check Current CPU Speed with cpu command on DietPi u get a wrong CPU Speed since it will always be the max CPU speed. During testing i noticed that cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq differs from vcgencmd measure_clock arm but vcgencmd seem to have the right value.

I tried to get all information that might be useful in this post but feel free to ask for more information.

External Bug RPi Solution available

Source

loizres

All 29 comments

Many thanks for your report.

Note that most commands draw enough CPU power to raise the frequency themselves for a tiny time frame. vcgencmd measure_clock arm shows indeed the currently effective frequency, but often the max raised clock (due to its own usage), if allowed by governor. cpu and /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq show what clock the CPU "should" have, means what the governor orders it to be, but there are situations where the CPU by firmware does not listen, e.g. thermal throttling, initial (on boot) or forced turbo boost (config.txt), a failure or other things. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is aimed to show the apparent frequency instead of the desired on, hence it should better match what vcgencmd measure_clock arm tells (in case there is any discrepancy), but it is all a question how exactly those sysfs files have been implemented.

We apply the CPU governor on boot via dietpi-preboot.service (systemctl status dietpi-preboot) which calls /boot/dietpi/func/dietpi-set_cpu to apply governor and available options. Check if it has been applied: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
In case check if the service status is fine and the script runs through without error.

If performance governor has been applied, then indeed you should always see highest clock on all levels. If this is not the case you found a bug that we need to forward to RPi kernel/firmware developers.
All I can say is that the governors work fine here on my RPi2 with current kernel version.

MichaIng on 17 Aug 2020

I'm not sure if i did understand everything but here is what i tested on RPi2 with governor set to performance after reboot:

root@BoincPi01:~# vcgencmd measure_clock arm frequency(48)=666666000
root@BoincPi01:~# vcgencmd measure_clock arm frequency(48)=666666000
root@BoincPi01:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 666666
root@BoincPi01:~# vcgencmd measure_clock armfrequency(48)=1000000000
root@BoincPi01:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 1000000

/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq seems to solve the issue too.
Maybe my Boinc setup causing an issue but i don't really think it should be a problem.

For systemctl status dietpi-preboot i get no Error:

root@BoincPi01:~# systemctl status dietpi-preboot
● dietpi-preboot.service - DietPi-PreBoot
   Loaded: loaded (/etc/systemd/system/dietpi-preboot.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2020-08-17 12:17:22 CEST; 11min 
ago
  Process: 219 ExecStart=/bin/dash -c /boot/dietpi/preboot 2>&1 | tee /tmp/dietpi-preboot.log (code=exited, tatus=0/SUCCESS)
 Main PID: 219 (code=exited, status=0/SUCCESS)

Aug 17 12:17:21 BoincPi01 systemd[1]: Starting DietPi-PreBoot...
Aug 17 12:17:22 BoincPi01 systemd[1]: Started DietPi-PreBoot.

loizres on 17 Aug 2020

Still strange that it first shows 667 MHz, with performance governor it should immediately and always be 1000 MHz. The performance governor is definitely active?

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

What is the CPU temperature?

vcgencmd measure_temp

MichaIng on 17 Aug 2020

root@BoincPi01:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
root@BoincPi01:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1000000
root@BoincPi01:~# vcgencmd measure_clock arm
frequency(48)=1000000000
root@BoincPi01:~# vcgencmd measure_temp
temp=62.7'C (on full load with boinc)
root@BoincPi01:~# reboot

Maybe i should note that this RPi2 is slightly overclocked to 1000 Mhz but i tried it on stock clock too. After reboot:

root@BoincPi01:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
root@BoincPi01:~# vcgencmd measure_clock arm
frequency(48)=666666000
root@BoincPi01:~# vcgencmd measure_temp
temp=56.8'C (on full load with boinc)
root@BoincPi01:~# vcgencmd measure_temp
temp=57.3'C
root@BoincPi01:~# vcgencmd measure_temp
temp=56.2'C (about 2 min from first measure) 
root@BoincPi01:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
666666
root@BoincPi01:~# vcgencmd measure_clock arm
frequency(48)=1000000000
root@BoincPi01:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1000000
root@BoincPi01:~# vcgencmd measure_temp
temp=60.5'C (full load about 1min in)

The temperatures fit to the output. Clock speed after reboot is idle clock speed.

loizres on 17 Aug 2020

Okay to prepare some bug report, please do/paste the following:

Upgrade firmware to latest version: apt update && apt upgrade
grep '^[[:blank:]]*[^#]' /boot/config.txt
reboot
-
cat /sys/devices/system/cpu/cpufreq/policy0/{affected_cpus,scaling_governor,scaling_cur_freq,cpuinfo_cur_freq,stats/time_in_state} vcgencmd measure_clock arm vcgencmd measure_temp vcgencmd get_throttled

I was not able to replicate on my RPi2, as fast as I apply the performance governor, it stays on highest clock (900 MHz). In seems in your case this is true after some time but not from the beginning? The commands above include checking for actual pstate stats and if any thermal throttling or frequency cap is or has occurred during current session.

There is a known issue with arm_freq_min that caused hang and crash issues when being lowered for lower idle frequencies. We hacked a fix via MOTD inside that commented that setting, when found and removed the option from dietpi-config. The RPi devs released a new firmware version where a lower arm_freq_min gets overwritten with default value (at least not below 600): https://github.com/raspberrypi/firmware/issues/1431
I was always thinking if not (only) the low clocks but the multiple pstate scaling is the culprit or certain frequencies that are now dynamically added/removed based on min/max clocks. Since you overclocked yours, instead of 600 MHz the lower clock is now 667 MHz, not sure if there is a third or this intermediate clock rate causes an issue? But you said you tested without overclocking as well, so it can be totally unrelated anyway.

MichaIng on 17 Aug 2020

root@BoincPi01:~# grep '^[[:blank:]]*[^#]' /boot/config.txt
disable_overscan=1
display_hdmi_rotate=0
lcd_rotate=0
gpu_mem_256=16
gpu_mem_512=16
gpu_mem_1024=16
max_usb_current=1
disable_splash=1
dtparam=audio=off
dtparam=i2c_arm=off
dtparam=i2c1=off
dtparam=spi=off
enable_uart=0
temp_limit=70
initial_turbo=20

-reboot-

root@BoincPi01:~# vcgencmd measure_clock arm
frequency(48)=600064000
root@BoincPi01:~# cat /sys/devices/system/cpu/cpufreq/policy0/{affected_cpus,scaling_governor,scaling_cur_freq,cpuinfo_cur_freq,stats/time_in_state}
0 1 2 3
performance
900000
600000
600000 655
900000 9184
root@BoincPi01:~# vcgencmd measure_clock arm
frequency(48)=900000000
root@BoincPi01:~# vcgencmd measure_clock arm
frequency(48)=900000000
root@BoincPi01:~# vcgencmd measure_temp
temp=56.2'C
root@BoincPi01:~# vcgencmd get_throttled
throttled=0x50000

This time the RPi2 was on stock clock.
I will test a clean install on my RPi2 but my RPi4 showed the same behaviour at least for Performance Govenor on a clean install and i will try another powersupply.

loizres on 17 Aug 2020

I've tried a fresh install with another powersupply but still same thing.

loizres on 17 Aug 2020

Ah there we found the reason: https://www.raspberrypi.org/documentation/raspbian/applications/vcgencmd.md

throttled=0x50000

This is bit 18 and 16 set, means it was throttled due to under-voltage. Only a short time but your output shows that while scaling driver wanted to apply 900 MHz the actual frequency right at the next line was 600 MHz.

When checking on the RPi4, when you see a lower clock rate, check vcgencmd get_throttled. The output above means it "was" throttled due to under-voltage, 0x5 (without trailing zeros) would mean it's currently throttled due to under-voltage and 0x50005 would mean both.

Solution is indeed a better PSU with stable voltage. Note that e.g. a USB charger, like one for mobile phone, is not made to provide a stable voltage which is not required to charge something, so you need a PSU that is produced to actually power a device. Also the cable can have a significant effect. I once used my great PSU with a bad cable I found laying around and ran into under-voltage as well. Changed it with a thicker one that was left from an old mobile phone (the cable, not the PSU 😉) solved the issue. Too thin cables (or bad connectors) can lead to significant voltage drop.

MichaIng on 17 Aug 2020

First of all thanks Micha for helping out here.
In my recent tests i brought up every USB cable and every PSU and or charger (with min output of 5V=2A) i could find without success. All tests with stock clock and CPU Governor set to Performance starts in idle clock. Two of the PSU i would consider as suitable but i'm no expert. Since u are not able to reproduce i think either my RPi2 is damaged or none of my PSU or cables are good enough to power it. Can u recommend a suitable PSU brand or product with several Ports? I red so much about bad PSU's causing trouble to different Devices like ESP recently that i was thinking of getting some good PSU. For the RPi2 i can live with the workaround since i reboot it rarely.

On my relatively new RPi4 with original Raspberry PSU this happens with Performance Governor set (in my tests only Performance not working on RPi4):

root@DietPi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
root@DietPi:~# vcgencmd measure_clock arm
frequency(48)=600117184
root@DietPi:~# vcgencmd get_throttled
throttled=0x0
root@DietPi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
600000
root@DietPi:~# vcgencmd measure_clock arm                                      
frequency(48)=1500345728
root@DietPi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1500000
root@DietPi:~# grep '^[[:blank:]]*[^#]' /boot/config.txt
disable_overscan=1
display_hdmi_rotate=0
lcd_rotate=0
gpu_mem_256=16
gpu_mem_512=16
gpu_mem_1024=16
max_usb_current=1
disable_splash=1
dtparam=audio=off
dtparam=i2c_arm=off
dtparam=i2c1=off
dtparam=spi=off
enable_uart=0
temp_limit=65
initial_turbo=20

-reboot-

root@DietPi:~# vcgencmd measure_clock arm                                       
frequency(48)=600169920
root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy0/{affected_cpus,scaling_governor,scaling_cur_freq,cpuinfo_cur_freq,stats/time_in_state}
0 1 2 3
performance
1500000
600000
600000 299
750000 0
1000000 0
1500000 7839
root@DietPi:~# vcgencmd measure_clock arm 
frequency(48)=1500345728
root@DietPi:~# vcgencmd get_throttled
throttled=0x0

Any ideas on this? I'm not really sure what throttled=0x0 means. If i understand the documentation right it seems to me that it means nothing but i ran in temperature limits already...

loizres on 18 Aug 2020

why scaling current freq different with command cpu ?

jakues on 18 Aug 2020

throttled=0x0 means nothing was ever throttled, nor was the soft temperature limit (60°C) ever reached. So even in this case you see non-max clocks with performance governor, now I'm out of explanations.

Could you try to remove initial_turbo? It should of course have an opposite effect but at least it affects the clocks on overrides the governor for the first 20 seconds, so probably this is somehow related.

I'd take the official RPi PSU for the model, never heard something bad of it, although one might find a similar or better quality for lower price if something about 2 €/$ counts.
I personally use a CSL 5V 2A power supply for my RPi2 and never had an issue with it, besides, on time a thunder/lightning close to our house broke it, kindly got a full free replacement. But I just checked where I bought it 2015 an now its nearly the same price as the higher current RPi4 official PSU with multiple plugs for international usage etc, so really no point in going with the CSL one, also since it does NOT come with a cable 😄.

Okay, see if initial_turbo has any effect. Else if clocks go down only on first minutes after boot, its probably not even a real issue, though strange.

why scaling current freq different with command cpu ?

The cpu command draws too much itself, raising clocks with ondemand governor. I always wanted to find some neat solution for this, e.g. sleeping for sampling_down time before reading the clocks. On the other hand the reason of current clock on a single print is anyway not high since it can be raised by any random event/cron/timer/server-access, so not sure if adding ~1s waiting time to this command is worth it.

MichaIng on 18 Aug 2020

throttled=0x0 means nothing was ever throttled, nor was the soft temperature limit (60°C) ever reached. So even in this case you see non-max clocks with performance governor, now I'm out of explanations.

Could you try to remove initial_turbo? It should of course have an opposite effect but at least it affects the clocks on overrides the governor for the first 20 seconds, so probably this is somehow related.

I'd take the official RPi PSU for the model, never heard something bad of it, although one might find a similar or better quality for lower price if something about 2 €/$ counts.
I personally use a CSL 5V 2A power supply for my RPi2 and never had an issue with it, besides, on time a thunder/lightning close to our house broke it, kindly got a full free replacement. But I just checked where I bought it 2015 an now its nearly the same price as the higher current RPi4 official PSU with multiple plugs for international usage etc, so really no point in going with the CSL one, also since it does NOT come with a cable smile.

Okay, see if initial_turbo has any effect. Else if clocks go down only on first minutes after boot, its probably not even a real issue, though strange.

why scaling current freq different with command cpu ?

The cpu command draws too much itself, raising clocks with ondemand governor. I always wanted to find some neat solution for this, e.g. sleeping for sampling_down time before reading the clocks. On the other hand the reason of current clock on a single print is anyway not high since it can be raised by any random event/cron/timer/server-access, so not sure if adding ~1s waiting time to this command is worth it.

OK thx

jakues on 18 Aug 2020

So i've tested to disable initial_turbo with 0 today and it works on RPi2 and 4. As u said when initial_turbo is set during bootup or expired after bootup it forces the clock to go down but not up anymore since Performance Governor was set already at early bootup. Do you think initial_turbo=0 setting should be implemented so there will be no problem in the future?
Thank you that we figured this one out and i really don't know why i didn't try to disable it before...

The last thing remaining is the different behavior of RPi2 and 4 on Conservative CPU Governor where RPi4 is working just fine but RPi2 needs a disabled initial_turbo. I don't really mind becausei i use Conservative only on RPi4 and on my tests it worked with no problem.

loizres on 19 Aug 2020

Btw with the modern kernel I would try schedutil governor. We don't have it in dietpi-config yet, actually a shame since it works pretty well and with less overhead. See here for details: https://www.kernel.org/doc/html/latest/admin-guide/pm/cpufreq.html#generic-scaling-governors
You'd need to manually set it in /boot/dietpi.txt, I'll add it soon to dietpi-config as well, I only need to take care to hide the non-effective tunables then.

Strange behaviour with initial_turbo and performance governor indeed. I'd have expected that they act completely independently, meaning the CPU ignores CPUfreq/scheduler as long as the firmware forces it to (initial_turbo, force_turbo, temp/voltage-related throttling) and immediately follows the scheduler policy once the firmware "releases" it, but I lack the technical insights. I'm wondering what exactly triggers max clock rate after a few minutes then 🤔.

On your RPi2 btw remember that low-voltage (was) mixed inside which might be responsible for your different picture compared to RPi4?

MichaIng on 19 Aug 2020

Btw with the modern kernel I would try schedutil governor. We don't have it in dietpi-config yet, actually a shame since it works pretty well and with less overhead. See here for details: https://www.kernel.org/doc/html/latest/admin-guide/pm/cpufreq.html#generic-scaling-governors
You'd need to manually set it in /boot/dietpi.txt, I'll add it soon to dietpi-config as well, I only need to take care to hide the non-effective tunables then.

Strange behaviour with initial_turbo and performance governor indeed. I'd have expected that they act completely independently, meaning the CPU ignores CPUfreq/scheduler as long as the firmware forces it to (initial_turbo, force_turbo, temp/voltage-related throttling) and immediately follows the scheduler policy once the firmware "releases" it, but I lack the technical insights. I'm wondering what exactly triggers max clock rate after a few minutes then 🤔.

On your RPi2 btw remember that low-voltage (was) mixed inside which might be responsible for your different picture compared to RPi4?

nah I want to try EAS on Raspberry Pi with schedutil governor

jakues on 20 Aug 2020

What is EAS? 😅

MichaIng on 20 Aug 2020

What is EAS? sweat_smile

See this

jakues on 20 Aug 2020

👍1

Awesome, yes that is what schedutil governor should allow, taking into account more metrics from the scheduler itself instead of CPU load only, reducing the change of contradictions between scheduler and governor decisions:

This governor generally is regarded as a replacement for the older ondemand and conservative governors (described below), as it is simpler and more tightly integrated with the CPU scheduler, its overhead in terms of CPU context switches and similar is less significant, and it uses the scheduler’s own CPU utilization metric, so in principle its decisions should not contradict the decisions made by the other parts of the scheduler.

MichaIng on 20 Aug 2020

Awesome, yes that is what schedutil governor should allow, taking into account more metrics from the scheduler itself instead of CPU load only, reducing the change of contradictions between scheduler and governor decisions:

This governor generally is regarded as a replacement for the older ondemand and conservative governors (described below), as it is simpler and more tightly integrated with the CPU scheduler, its overhead in terms of CPU context switches and similar is less significant, and it uses the scheduler’s own CPU utilization metric, so in principle its decisions should not contradict the decisions made by the other parts of the scheduler.

on android EAS good for battery backup nad CPU not load too much
I hope dietpi bring EAS

jakues on 20 Aug 2020

We do not kernel development, so it depends on the RPi foundation. From what I read EAS is part of Linux since 5.0 and further implemented/enhanced with every version. Not sure if/which flag or kernel option needs to be switched to enable it, the Linux docs give some hints: https://www.kernel.org/doc/html/latest/scheduler/sched-energy.html
Same is true for Armbian kernel, (future) Odroid kernels and (Bullseye) Debian x86_64 kernels, that we use, basically we need to check whether this is a topic already and otherwise kindly make it one to consider. But all this is a bid over my knowledge/competences, also for which kind of platforms a reasonable effect can be expected without significant downsides. Also mobile phones seem to be the driver currently, while of course power usage IMO should be a major topic for all kind of systems, also since it is directly correlated to heat/cooling effort.

MichaIng on 20 Aug 2020

Strange behaviour with initial_turbo and performance governor indeed. I'd have expected that they act completely independently, meaning the CPU ignores CPUfreq/scheduler as long as the firmware forces it to (initial_turbo, force_turbo, temp/voltage-related throttling) and immediately follows the scheduler policy once the firmware "releases" it, but I lack the technical insights. I'm wondering what exactly triggers max clock rate after a few minutes then thinking.

On your RPi2 btw remember that low-voltage (was) mixed inside which might be responsible for your different picture compared to RPi4?

Max clock rate didn't trigger after a few minutes it only triggered when i cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor or changed CPU Governor. Just wanted to clearify this because i think you misunderstood me.

I'm not sure if low-voltage causes the problem. If i understand vcgencmd get_throttled 0x50000 correct it says that there was an undervoltage and thus throtteling but not when it has happened. The RPi2 was operated with low voltage once and maybe this damaged the RPi slightly but i don't really believe this. The RPi is now overclocked with full load and working stable as far as i can say. Anyway since you are not able to reproduce this and i have a working solution i don't want to bother you.

For my RPi4 i will try shedutil thanks for mentioning. This beast can get really hot especially with hot temperatur outside now.

loizres on 21 Aug 2020

Okay got it. Somehow accessing the tuneable seems to trigger a governor refresh then. Probably this is a performance+powersave only issue since those basically set a single clock rate once and are done. Maybe there is a way (for kernel/firmware development) to re-trigger the governor once any kind of firmware clock override has finished, being it initial_turbo, thermal- or voltage-related throttling.

Yes 0x50000 means it "was" throttled due to low voltage, but it could be the case regularly for short time frames not necessarily only once at boot. AFAIK there is no monitor/timestamp for this, besides, when you attach a monitor you should see a rainbow coloured square at the screen whenever low-voltage is detected. Besides that certain parts of the hardware can fail, leading to data loss or service or whole system freeze/crash, AFAIK there is no chance it "damages" the SBC hardware. Too high voltage would 😄.

MichaIng on 21 Aug 2020

I just found the following firmware update notes: https://github.com/raspberrypi/firmware/commit/a490197f0672d948860b2b807884ae65eabc4d4f

firmware: Revert arm_loader: Move first call to set_turbo after arm->start

No further hint with which version the change has been done that is reverted here, or any link to any reported issue, but a changed order when the (initial) turbo is set might effect such behaviour.

I retested with a newer kernel, not including the commit above but newer than current stable:
_NB: I lowered the idle/min frequency too 100 MHz for testing 😉._

2020-09-16 12:18:20 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:18:24 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:18:26 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:18:27 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:18:37 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:18:38 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:20:57 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:20:58 root@micha:~# htop
2020-09-16 12:21:23 root@micha:~# uname -a
Linux micha.gnoedi.org 5.4.59-v7+ #1336 SMP Wed Aug 19 16:03:09 BST 2020 armv7l GNU/Linux
2020-09-16 12:23:59 root@micha:~# vcgencmd get_config initial_turbo
initial_turbo=20
2020-09-16 12:24:37 root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
performance
2020-09-16 12:25:05 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:25:52 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:26:06 root@micha:~# cpu

 ─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     armv7l
 Temperature  |     39'C : 102'F (Cool runnings)
 Governor     |     performance

                 Current Freq    Min Freq   Max Freq
 CPU0         |      900 MHz      100 MHz    900 MHz
 CPU1         |      900 MHz      100 MHz    900 MHz
 CPU2         |      900 MHz      100 MHz    900 MHz
 CPU3         |      900 MHz      100 MHz    900 MHz

[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.

2020-09-16 12:26:12 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:26:16 root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq
900000
2020-09-16 12:26:36 root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq
900000
2020-09-16 12:26:40 root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
100000
2020-09-16 12:26:53 root@micha:~# vcgencmd measure_clock arm
frequency(48)=900000000
2020-09-16 12:27:02 root@micha:~# vcgencmd get_throttled
throttled=0x0

🈴 Clear case, there is a bug. Even cat scaling_governor does not trigger the frequency to go up, or the delay is large, after cat cpuinfo_cur_freq made it finally going up. The governor is requesting/has requested max frequency but it is not applied as the "actual" frequency (vcgencmd measure_clock arm should be most reliable on RPi) shows.

Now updating to lasted master (including the commit above), lets see if this fixes it.

MichaIng on 16 Sep 2020

🈴 Same issue with latest master:

... this is already ~2 minutes after boot
2020-09-16 12:47:43 root@micha:~# vcgencmd get_throttled
throttled=0x0
2020-09-16 12:47:59 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:48:05 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:48:21 root@micha:~# vcgencmd get_config initial_turbo
initial_turbo=20
2020-09-16 12:48:31 root@micha:~# htop
2020-09-16 12:49:10 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:49:12 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:49:14 root@micha:~# vcgencmd measure_clock arm
frequency(48)=100000000
2020-09-16 12:49:15 root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
100000
2020-09-16 12:49:32 root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
900000