Dietpi: RPi 3 B+ / Temperature question

[helmethawthorn]

Creating a bug report/issue:

(Referring to https://dietpi.com/phpbb/viewtopic.php?f=9&t=3873)

Hi all, I have just bought my first Raspberry and I am doing my first steps. - My goal is to run Pi-Hole on it. Having started with Raspbain Stretch Lite, I read about DietPi - and it sounds very good and interesting. So, I re-installed it with DietPi. :D

I am wondering why the displayed CPU temperature is higher, when I run on DietPi.

Any idea, what the reason is?
Thank you very much!

Required Information:

• DietPi version | 6.9
• Distro version | stretch / 9.4
• Kernel version | 4.14.44-v7+
• SBC device | RPi 3 Model B+ (armv7l)
• Power supply used | original Raspberry Pi 3 / 5V 2.5A
• SDcard used | SanDisk ultra, SDHC, 32GB

Additional Information (if applicable):

• Software title | Pi-Hole
• Freshly installed right after setting up DietPi
• Yes
• 1f580197-5c1d-47de-bb59-84a00415282a

Steps to reproduce:

1. Start from scratch with Dietpi / re-install on SD-card
2. Let first install routine run (incl. updates)
3. Install Pi-Hole from DietPi Software menu
4. Watch temperatures via Ph-Hole Web frontend or with watch "cat /sys/class/thermal/thermal_zone0/temp"

Expected behaviour:

I was expecting temperatures to be as low as with original Raspbian image.
Perhaps even a little bit lower, as DietPi runs fewer processes and because I changed the CPU profile to "conservative" which should prefer slower CPU frequencies.

Actual behaviour:

Temperature is slightly higher when running on DietPi. Of course, that's not really bad now. But as higher temperature means faster aging, I am wondering what the cause is.

Extra details:

I use the original Raspberry case and I did some tests with the top cover mounted and some without. Here are the results (average calculated from 13 measurements):

WITH top cover:
DietPi: 57,5 (+2,6)
Raspbian: 54,9

WITHOUT top cover:
DietPi: 51,0 (+3,1)
Raspbian: 47,9

As requested, I will attach my /boot/config.txt.

[helmethawthorn]

config-txt-dietpi.txt

[MichaIng]

I can confirm the issue on fresh DietPi v6.9 (although in my case Buster testing installation) vs fresh Raspbian Lite pre-image:

Raspbian Lite:

root@raspberrypi:~# echo CPU: $(( $(</sys/class/thermal/thermal_zone0/temp) / 1000 )) GPU: $(vcgencmd measure_temp)
CPU: 40 GPU: temp=40.1'C
root@raspberrypi:~# vcgencmd measure_clock arm
frequency(45)=600000000

DietPi Buster:

2018-06-09 22:52:44 root@micha:~# echo CPU: $(( $(</sys/class/thermal/thermal_zone0/temp) / 1000 )) GPU: $(vcgencmd measure_temp)
CPU: 45 GPU: temp=45.5'C
2018-06-09 22:52:50 root@micha:~# vcgencmd measure_clock arm
frequency(45)=900000000

• Even after 15 idle minutes with 0.00 / 0.00 / 0.00 usage, clock and temperature stay the same,
• Using default config.txt leads to 600 Mhz and 40 °C. Then trying to put the DietPi default settings inside and:
• Found 'initial_turbo' to be the problem. Should be 20 seconds, but clock stays at 900 MHz forever or wayyy longer. When taking this setting out, clock goes down to 600 MHz and temperatures to ~40 °C.

I see you installed the newest kernel via rpi-update / dietpi-config? That would have been the next step, as I am on current APT kernel 4.14.34. So this is sadly no single version bug.

@helmethawthorn
Thank you very much for the report btw. The forum indeed is a good start point to share issues, but don't hesitate to open an issue here on github as well, even if you are not sure if it's a bug or a usage issue 😉. DietPi aims to be user friendly, so everything should behave as users (with less Linux experience) would expect it.

Could you try to comment the line, reboot and see if the issue persists or is solved as it was for me? sed -i 's/initial_turbo/#initial_turbo/' /DietPi/config.txt

Further reference:
https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&start=425#p180099

• Can't find something about changed setting behaviour. 20 should lead to 20 seconds turbo, nothing more.
• After wrong behaviour confirmation we should open an issue on their github repo: https://github.com/raspberrypi/firmware/issues

[helmethawthorn]

That's interesting!

Although I set the CPU profile to "conservative" and although the command "cpu" shows "Current Freq: 600 MHz",...

 ─────────────────────────────────────────────────────
  DietPi CPU Info
  Use dietpi-config to change CPU / performance options
  ─────────────────────────────────────────────────────
  Architecture |     armv7l
  Temp         |     57'c : 134'f  | Running warm, but safe.
  Governor     |     conservative
  Throttle up  |     50% CPU usage

                  Current Freq    Min Freq   Max Freq
  CPU0         |      600 MHz      600 MHz    1400 MHz
  CPU1         |      600 MHz      600 MHz    1400 MHz
  CPU2         |      600 MHz      600 MHz    1400 MHz
  CPU3         |      600 MHz      600 MHz    1400 MHz

...when issuing the command you used ("vcgencmd measure_clock arm") I get this:
frequency(45)=1400000000.
I let it run with "watch" for 30 minutes - and the value never changed.
Does that mean that my RPi runs with full speed all the time instead of throttling? I assume there should be a "600000000" at least sometimes, shouldn't it? ;-)

Will try now to boot without the initial_turbo. Thank you very much!

@MichaIng: I am happy to be able to do my part to make DietPi even better - even if it is only a veeeery small part. - Great software! :-)

[MichaIng]

@helmethawthorn
Did you try to remove/comment the initial_turbo setting in /DietPi/config.txt?

Hmm so cpu shows current clock = 600 MHz while vcgencmd measure_clock arm shows 1400 at the same time?? This is strange. On my RPi2 both show definitely the current clock (not max clock) and cpu mostly show 1 or 2 cores up at 900 MHz (max for RPi2) due the the script internal load.
It would not make much sense, but maybe the command on RPi3 somehow shows the max clock instead of current? Sadly I have no RPi3 here to investigate, maybe @Fourdee finds some time.

One thing: DietPi default Throttle up is by default at 50% as you can see, which is quite low compared to default, AFAIK. I e.g. use for server only system 85%, as also recommended within performance settings. You could check the default cat /sys/devices/system/cpu/cpufreq/conservative/up_threshold respectively cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold at Raspbian Lite, in case adjust this within DietPi and check if this leads to equal temperatures.

[helmethawthorn]

@MichaIng
Meanwhile I have done some testing. With the new (=commented) setting in /DietPi/config.txt, I get the following results:

• Temperature with top cover: 53,6

  • -3,9 C !
  • (Load 0.00 0.00 0.00)

• Temperature without top cover: 47,5

  • -3,5 C
  • Load 0.08 0.03 0.01

# vcgencmd measure_clock arm
frequency(45)=600000000

 ─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     armv7l
 Temp         |     48'c : 118'f | Optimal temperature.
 Governor     |     conservative
 Throttle up  |     50% CPU usage

                 Current Freq    Min Freq   Max Freq
 CPU0         |      600 MHz      600 MHz    1400 MHz
 CPU1         |      600 MHz      600 MHz    1400 MHz
 CPU2         |      600 MHz      600 MHz    1400 MHz
 CPU3         |      600 MHz      600 MHz    1400 MHz

Questioning the max/default/current clock settings, you had the right idea, right from the start!

Hmm so cpu shows current clock = 600 MHz while vcgencmd measure_clock arm shows 1400 at the same time?? This is strange.

Indeed. However, with the changed config.txt both are the same now.
When I fire the "cpu" command several times directly one after the other, all cores go straight up to 1.400 MHz. Otherwise they stay at 600 MHz and it seems nothing can make them go up. Maybe the result of the (now working) "conservative" setting?

One thing: DietPi default Throttle up is by default at 50% as you can see,...

Thank you for this hint. :-) I didn't change it before, this is the setting right after the installation. I have increased the value to 85.

By the way: the "Recommended value" for the "ARM Temp Limit" is 65 C - but the configured value is 75 C after the installation. Is there a specific reason for this?

[helmethawthorn]

You could check the default cat /sys/devices/system/cpu/cpufreq/conservative/up_threshold respectively cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold at Raspbian Lite, in case adjust this within DietPi and check if this leads to equal temperatures.

I quickly booted up the "Raspbian SD card". ;-) And "cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold" says "50". The same as after a fresh DietPi installation. "vcgencmd measure_clock arm" shows 600.

But as the temperature is even a tiny bit lower with DietPi (compared to running on Raspian), I am happy now.

Thank you very much for your help!

PS. 40 C? Why is your temperature that low? Is this normal for a RPi2? Or is your room temperature lower? I have 26 C. ;-)))

[MichaIng]

@helmethawthorn
Ah, throttle up at 50% is default? Okay that's just another cause elimination then 🙂.

Thank you very much for testing and reporting. Great that we found the cause and even obviously a kernel settings issue that affects all RPi versions (at least 2 and 3). Seems that the initial_turbo somehow breaks CPU governor settings. Just checked past PRs about this: https://github.com/raspberrypi/firmware/search?q=initial_turbo&type=Commits

Maybe firmware: arm_loader: Don't lose force_turbo when initial_turbo completes preserves turbo even if no turbo was set. No idea, I will create an issue about this.

Hmm the last think we could test, just to be sure, is setting initial_turbo on Raspbian Lite and see if it has the same effect there.

---

Issue: https://github.com/raspberrypi/firmware/issues/1005

[helmethawthorn]

@MichaIng
Thanks again for YOUR help! Is there anything I can help you with right now?
Does this bug report stay open for further comments/actions or shall I close it, now that the root cause is clear? (Sorry, - I have never used GitHub before. ;-))

[MichaIng]

@helmethawthorn
We can keep the issue opened until we have some reaction from the raspberrypi repo, so we will not forget the issue, if the reaction takes some time 😉.

In case, for v6.10:

• Remove initial_turbo from default config.txt.
• Remove initial_turbo via patch_file.

[helmethawthorn]

Okay! :-)

Any clue why I have only 5 emojis? No smileys at all, - only 👍 👎 💯 🔢 and 🥇.

[MichaIng]

@helmethawthorn
After typing :, start to enter some more letters so see other emojis. :smiley: e.g.

[Fourdee]

@MichaIng

Impressive debugging and finding the cause, great work 👍

[MichaIng]

As we have another possibly kernel related RPi issue, I just add it here, so we have one place to follow both issues:
Forum: https://dietpi.com/phpbb/viewtopic.php?f=11&t=3886
GitHub: https://github.com/raspberrypi/firmware/issues/1006

In short: rpi-update/4.14.48 seems to break SDcard/the possibility for kernel to mount root.

[MichaIng]

Added PR to fix OT issue: https://github.com/Fourdee/DietPi/pull/1859
We should keep an eye on the RPi firmware issue and revert in case of fix arrived in stable (APT) repo.

[Fourdee]

@MichaIng

Great work, tested fine on RPi 3B+ 👍

[MichaIng]

I mark as closed, until we have some solution from RPi firmware side.

[helmethawthorn]

@MichaIng - Hi, long time no see! ;-))

I have just updated my DietPi to v6.26.3, which re-adds the "initial_turbo" setting again. When the window popped up while updating I remembered taking my first steps on RPi here on Github, - nearly 1.5 years ago. ;-)

Unfortunately, the initial_turbo option does NOT work for me. Instead, the CPU freq stays at 1.4GHz again - and the temps raise. When I comment the turbo option out, the CPU freq goes down to 600MHz again. - Have checked it several times.

I have also set the value to "2", just in case someone changed it from seconds to minutes. ;-)

Is there anything else I could to do?

Thank you and kind regards!

[helmethawthorn]

watch "cat /sys/class/thermal/thermal_zone0/temp && vcgencmd measure_temp && vcgencmd measure_clock arm"

WITH "initial_turbo" *

60148
temp=60.1'C
frequency(45)=1400000000

WITHOUT "initial_turbo" *

57458
temp=57.5'C
frequency(45)=600000000

[MichaIng]

@helmethawthorn
Many thanks for your report.

That is very strange, we tested it up and down with several users (RPi dev side as well) on RPi2+3+4 and it worked (and in my case works) very well 🤔.

Which kernel version do you use? uname -r
You use ondemand governor? cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
And to assure that it indeed never is in 600 MHz state when booting with initial_turbo: cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state

And it is still the time in seconds 😉. Values over 60 (1 minute) are not allowed/ignored anyway.