"initial_turbo" setting within "config.txt" breaks throttle down of ARM clock

[MichaIng]

Ref: https://github.com/Fourdee/DietPi/issues/1836

We found that if initial_turbo is set in config.txt somehow breaks the CPU governor to throttle down ARM clock according to governor rules. Removing/commenting the setting resolves the issue.

We checked on RPi2 and RPi3 B+ and with current Buster APT kernel 4.14.34-v7+ (RPi2) and 4.14.44-v7+ via rpi-update (RPi3 B+) with initial_turbo=20 which's effect should fade 20 seconds after boot.

Steps to reproduce:

1. Use CPU governor settings that allow throttle down on idle.
2. Without initial_turbo watch lowered CPU clock and stable temperatures.
3. Add initial_turbo=20, reboot and watch CPU clock stay at highest level and temperatures around 5 °C higher.

[JamesH65]

@popcornmix @pelwell This does appear to be an issue. Done a quick check on Pi3B+, and both vcgencmd measure_clock arm and cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq shoq 1400000 permanently after using initial_turbo. Any quick thoughts, if not I'll dig around a bit. Quick look at the code and it does look sane, so nothing obvious jumping out.

[MichaIng]

@JamesH65
Thanks for verifying, also that it is still an issue. Did not retest with new kernels.

It is no big issue, if known, since usually CPU power does not limit the boot time very much, but it is an issue, if users don't know it and wonder why their RPi is running hot with constant high clock and power consumption, without any obvious possibility to change or resolve that.

[JamesH65]

There's clearly an issue here, and its in an important area, so we will look in to it.

[BigMuscle85]

I can confirm that this issue still appears on kernel 4.19.49-v7+.
scaling_cur_freq return correct frequency, vcgencmd measure_clock returns 1.4 GHz (or 1.2 GHz if temp > 60°C) and measured power consumption does not change with "powersave" and "performance" scaling governors.

[MichaIng]

@JamesH65
Just as a bump up, any news on this?

[popcornmix]

I'm working on something in this area. I'll take a look.

[popcornmix]

This should be fixed in latest rpi-update firmware. Please test.

[MichaIng]

@popcornmix
Perfect, will run some test later.

[MichaIng]

@popcornmix
Seems to work fine, CPU is throttled down with ondemand governor as expected. Is there any way to check whether the initial turbo is active and when it is disabled due to defined time reached?

---

Hmm, I just set:

# vcgencmd get_config initial_turbo
initial_turbo=60

On boot, via script, CPU governor is set to ondemand.
I checked frequency some seconds after boot, definitely prior to 60 seconds reached and it already throttled down:

# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq
300000

Does applying a governor interfere or is there anything else required to have initial_turbo being effective? This is a Raspbian-based image but I removed a large amount of non-required packages. All firmware packages from repo + rpi-update on top of course are installed.

---

Ah docs state it is active "until cpufreq set freq". cpufrequtils is not installed by default on Raspbian, so what I can think of is the raspi-config service that sets ondemand governor? But it does not set the freq itself...

[popcornmix]

initial_turbo isn't something that kernel cpufreq driver knows about, so scaling_cur_freq will report what the kernel requested. You should use:
vcgencmd measure_clock arm
to see the actual frequency. When I reboot with initial_turbo=60 I see straight after boot:

pi@pi4:~ $ vcgencmd measure_clock arm
frequency(48)=1500398464

and then after the 60 seconds have elapsed:

pi@pi4:~ $ vcgencmd measure_clock arm
frequency(48)=600117184

[l4jos]

Same throttling issue on my RPi 4b. I am in doubt about returning the device to the store unfortunately.
I tried the stock firmware out of the box, and the latest firmware from rpi update channel aswell. So far I can remember, RPi 4b latest firmware from last week got +- 68-70C.

Can some otherone confirm if the solution works? I am at work at the moment.

Ref: MichaIng/DietPi#1836

We found that if initial_turbo is set in config.txt somehow breaks the CPU governor to throttle down ARM clock according to governor rules. Removing/commenting the setting resolves the issue.

This will made my day.

[popcornmix]

If your pi is at 68-70C then there is no throttling. Can you explain what your issue is?

[MichaIng]

Also initial_turbo AFAIK does not break thermal throttling, just idle throttling initiated by the ondemand/conservative CPU governor. RPi4 is known to have high idle temperatures, even when throttled down successfully, requiring an active cooling in most cases.

Sorry btw for not confirming the test so far, was distracted by other topics. I understood now that /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq shows the "wanted" clock by the kernel/governor while vcgencmd measure_clock arm shows the actual current clock, estimated at a lower hardware level.
I hope I find time to spin-up the testing system later this week, just to provide some final confirmation and close the issue 🙂.

[pelwell]

Installing the latest USB3 HC firmware is likely to reduce your idle temperature by a few degrees. A download link and instructions can be found here: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=250990

[l4jos]

If your pi is at 68-70C then there is no throttling. Can you explain what your issue is?

I forgot which temperature, it could be 10 more (not home and I'm having discalculia).
Anyway, movies are slow in terms of video playback. Menu in kodi has glitchy image as well. It looks like artifacts. LibreELEC has this as well. I was thinking about a device or CPU issue.
I am not sure. This is a problem, it appeared out of the box.
It is not a buffering issue, because movie stream is continiously.

What do you think. Hope, or some kind of RIP?

[popcornmix]

Tearing in kodi gui is a known software issue.
Movies playing slowly won't be a hardware issue.
Note that kodi on a Pi4 is currently considered alpha.

If you don't see a thermometer icon in the top right on screen then you are not temperature throttling. Your issues don't sound like hardware issues.

[MichaIng]

Especially on RPi4 (thus Raspbian Buster), when you simply install via apt install kodi, it will install the non-compatible version from Raspbian repo, which does not come with GPU acceleration support or does not start at all. So slow video playback is then expected for high resolution videos at least, although... perhaps RPi4 ARM can manage it without GPU as well, just running hot then.

There is a custom compiled version that can be found on the raspberrypi.org forums.

[l4jos]

The lack of the soc cooler is the biggest problem of everything. Ofcourse it will throttle after it reaches max TJunction

[MichaIng]

@popcornmix
Okay finally I managed to test with the new firmware, sadly it still doesn't throttle down in my case:

root@DietPi:~# uname -a
Linux DietPi 4.19.71-v7+ #1263 SMP Thu Sep 12 16:20:44 BST 2019 armv7l GNU/Linux
root@DietPi:~# vcgencmd get_config initial_turbo
initial_turbo=60
root@DietPi:~# vcgencmd get_config force_turbo
force_turbo=0
root@DietPi:~# vcgencmd get_config arm_freq
arm_freq=900
root@DietPi:~# vcgencmd get_config arm_freq_min
arm_freq_min=300
root@DietPi:~# vcgencmd measure_clock arm && cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_cur_freq
frequency(45)=900000000
300000
root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
25000
root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
40
root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
ondemand

• This was several minutes after boot on an RPi2 PCB v1.1.
• As can be seen, ondemand governor is active and wants to throttle down to 300 Mhz.
• ARM frequency stays at 900 Mhz.
• Due to sampling_rate * sampling_down_factor = 1 second, it is impossible that between both values read the governor changes its mind. As well I monitored both values for a longer time of course.
• I retried with initial_turbo=30 with same result.
• With initial_turbo=0 again the ARM throttles down as wanted:

root@DietPi:~# vcgencmd get_config initial_turbo
initial_turbo=0
root@DietPi:~# vcgencmd measure_clock arm && cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_cur_freq
frequency(45)=300000000
900000

• The values are reversed since the vcgencmd execution itself causes enough CPU usage to have the governor throttling up 😉. During the test above this was not the case, since CPU usage limit is not reached with 900 MHz.

Not sure if I missed something, or any other test/debug I can do?

[popcornmix]

I'm sorry. We currently have separate branches for Pi4 and Pi0-3.
The fix is only currently on Pi4 branch.
I've cherry-picked it to other branch, so should appear in next rpi-update firmware.

[popcornmix]

Latest rpi-update firmware should have fix in Pi0-3 firmware too.

[BigMuscle85]

This should be fixed in latest rpi-update firmware. Please test.

Clean Raspbian Buster:
official firmware 4.19.66-v7+, problem appears.
rpi-update to 4.19.73-v7+, problem seems to be fixed.
Thank you.

[MichaIng]

I can confirm, bug is fixed, just tested on RPi2 via:

watch 'vcgencmd measure_clock arm; cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_cur_freq'

• Right after boot/login

frequency(45)=900000000
300000

• After defined time

frequency(45)=300000000
300000

@popcornmix
Many thanks, great work 👍, I mark this issue as closed.

[MichaIng]

Kernel version with fix has been uploaded to APT repo today 👍. Re-adding initial_turbo to my config provided a massive boot time reduction, since RPi boots with powersave governor until e.g. raspi-config CPU service (or a custom one) sets this.

Without initial_turbo, setting CPU governor to ondemand via early running systemd unit:

2019-10-10 18:14:49 root@micha:~# systemd-analyze
Startup finished in 3.498s (kernel) + 32.207s (userspace) = 35.705s
graphical.target reached after 32.107s in userspace

After setting initial_turbo=20:

2019-10-10 18:28:09 root@micha:~# systemd-analyze
Startup finished in 1.334s (kernel) + 10.063s (userspace) = 11.398s
graphical.target reached after 9.964s in userspace

[MichaIng]

@popcornmix
There has been an issue reported with initial_turbo on RPi4 with current firmware release: MichaIng/DietPi#3131 (comment)

• initial_turbo in combination with overclocking breaks boot.
• The same overclocking profile proves stable by booting without initial_turbo and doing some CPU stress test.

Do you have any idea what initial_turbo might do differently compared to a CPU stress test? Are clock rates, overvoltage and such applied in the right order or might there be other reasons why higher clock rates on early boot cause issues while they work perfectly stable when applied to running systems, respectively become effective at later boot stage by applying CPU governor?