Running at higher temperature since v8.1.2

[Uli007git]

Just an observation that the pi 4B with 4 Gigs of RAM is now running approx. 5 degrees warmer. I just installed it a few days ago, same setup software wise as before... 48°C now

Required Information

• DietPi version | 8.1.2

• SBC model | Pi 4b 4 Gigs

• SD card used | SSD

[Joulinar]

Something I'm not able to confirm. My RPi4B production system is still running same temperature. What apps you are running?

You could use htop to check for CPU consuming processes.

[MichaIng]

Many thanks for your report.

From which version did you upgrade, or when did you run apt upgrade the last time?

It could be related to the last kernel upgrade, though I didn't hear or recognise such yet. Can you show the output of cpu and verify that scheduler, min and max frequencies are still the same?

[Uli007git]

Something I'm not able to confirm. My RPi4B production system is still running same temperature. What apps you are running?

You could use htop to check for CPU consuming processes.

screenshot 2022-02-13 um 18.09.34.pdf

It's definitely not so busy

[Uli007git]

From which version did you upgrade, or when did you run apt upgrade the last time?

not sure from which version I upgraded... it was 8 something... I just upgrade when I got a message to upgrade.

It could be related to the last kernel upgrade, though I didn't hear or recognise such yet. Can you show the output of cpu and verify that scheduler, min and max frequencies are still the same?

I didn't change anything

─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     aarch64
 Temperature  |     47 °C / 116 °F : Optimal temperature
 Governor     |     schedutil

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1100 MHz      600 MHz    1500 MHz
 CPU1         |      1100 MHz      600 MHz    1500 MHz
 CPU2         |      1000 MHz      600 MHz    1500 MHz
 CPU3         |      1000 MHz      600 MHz    1500 MHz

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

[MichaIng]

Can you also check:

vcgencmd measure_temp
vcgencmd measure_clock arm

To assure that the temperature is correct and that the CPU frequency is not overridden by the firmware.

[Joulinar]

Did you tried to reboot? Did you have done a PiHole update as well? I see some load on Unbound + PiHole. On my system they don't consum any CPU at all.

[Uli007git]

Can you also check:

vcgencmd measure_temp

temp=48.7'C

vcgencmd measure_clock arm

frequency(48)=1100302720

[MichaIng]

Okay this looks all correct. Whether Pi-hole and Unbound produce some load of course also depends on whether there are currently DNS queries incoming or not. When you repeat vcgencmd measure_clock arm a few more times, does it lower in cases down to at least 700 MHz (the last 100 MHz to min could be impossible considering the load of the command itself and the quick reaction of the schedutil governor).

[Uli007git]

Did you tried to reboot? Did you have done a PiHole update as well? I see some load on Unbound + PiHole. On my system they don't consum any CPU at all.

PiHole is up to date ... I just rebooted... hmm... it's now maybe 1 or two degrees lower

dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=47.7'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.7'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=45.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=47.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=45.7'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=47.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.7'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=47.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.7'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.7'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.7'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.2'C
dietpi@myserver:~$ sudo vcgencmd measure_temp
temp=46.2'C

[Uli007git]

Okay this looks all correct. Whether Pi-hole and Unbound produce some load of course also depends on whether there are currently DNS queries incoming or not. When you repeat vcgencmd measure_clock arm a few more times, does it lower in cases down to at least 700 MHz (the last 100 MHz to min could be impossible considering the load of the command itself and the quick reaction of the schedutil governor).

this helps?...

dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1000265600
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100302720
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1000212864
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1000265600
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100249984
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100302720
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100302720
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1000212864
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100302720
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1200287104
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100249984
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1200287104
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100249984
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100249984
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100302720
dietpi@myserver:~$ sudo vcgencmd measure_clock arm
frequency(48)=1100249984

[MichaIng]

Hmm, it stays at >=1 MHz 🤔. Can you show it related to CPU usage:

for i in {1..10}; do G_OBTAIN_CPU_USAGE; G_OBTAIN_CPU_TEMP; sleep 0.5; done

When you watch htop a little longer, is there something constantly at a notable CPU usage (aside of htop itself)? When it's indeed Pi-hole and Unbound, probably a network client is sending many DNS requests in a failure loop or such, i.e. check Pi-hole query logs.

[Uli007git]

Hmm, it stays at >=1 MHz 🤔. Can you show it related to CPU usage:

for i in {1..10}; do G_OBTAIN_CPU_USAGE; G_OBTAIN_CPU_TEMP; sleep 0.5; done

I need to write an executable script? NOOB :(

When you watch htop a little longer, is there something constantly at a notable CPU usage (aside of htop itself)? When it's indeed Pi-hole and Unbound, probably a network client is sending many DNS requests in a failure loop or such, i.e. check Pi-hole query logs.

how do I check the pi-hole query logs? :)

[MichaIng]

I need to write an executable script? NOOB :(

Simply copy and paste that line into your SSH console. It will print 10 times CPU temperature and usage over 5 seconds.

how do I check the pi-hole query logs? :)

With the admin web interface. There is a list of the last queries, so you can check if there are many, probably blocked or failing ones, in short time range.

[Joulinar]

There is as well a Dashboard showing the top clients. Just have a look.

[Uli007git]

I need to write an executable script? NOOB :(

Simply copy and paste that line into your SSH console. It will print 10 times CPU temperature and usage over 5 seconds.

0,2 45 0,2 44 0,2 44 0,2 44 0,2 44 0,2 44 0,2 45 0,2 45 0,2 44 0,2 44

how do I check the pi-hole query logs? :)

With the admin web interface. There is a list of the last queries, so you can check if there are many, probably blocked or failing ones, in short time range.

ok

[Uli007git]

There is as well a Dashboard showing the top clients. Just have a look.

I just see that the temp went down after the reboot... so it seems it was only temporary... maybe caused by pihole.

[Joulinar]

PiHole released a new version yesterday. Did you performed this update? Maybe something stuck after the update causing higher load. And it got solved by the reboot.

[Uli007git]

PiHole released a new version yesterday. Did you performed this update? Maybe something stuck after the update causing higher load. And it got solved by the reboot.

🤷🏻‍♂️ Yeah… let’s close it, thanks guys 😊

[MichaIng]

Though 0.2 is a pretty low CPU usage (it is percent, not per 1 per core). However, good that it solved itself. If CPU temperatures goes up again, as said, checking Pi-hole query logs in its web interface are something to check. It's sometimes also faulty clients which keep sending blocked or otherwise failed requests in a burst, especially macOS/iOS had some strange behaviour regarding this with the default 0.0.0.0 blocking method, if I remember right some cases reported on the Pi-hole forum.