Daemon to set scaling_max_freq according to CPU temperature

[pa4wdh]

Hi All.

I recently got myself a new PC based on a Asrock J5040-ITX mainboard. The processor is 2.0GHz but thanks to a turbo mode it can scale from 800MHz upto 3.2GHz.

When using a standard cpufreq governor it will be set to 3.2GHz when under load and it will stay there. Since this is a fanless system, heat builds up and eventually even reaches it's critical temperature (95 degrees Celsius).
One way to prevent that from happening is to lower the scaling_max_freq cpufreq setting, but of course if temperatures allow it i'd like to use the full capability of the CPU. So what i need is a daemon that monitors the CPU temperature and lowers the scaling_max_freq when the temperature rises above a certain threshold and increases scaling_max_freq if the temperature allows it.

I made a small proof-of-concept shell script that does exactly that and it works. Now I expect this problem to be so common that i expect someone else has made a nice program that does this, i've checked all programs in sys-power/ but I can't find it. Is anyone aware of a program that does this?

Thanks in advance.

[pa4wdh]

As it seems my case is not as common as i expected, and i haven't been able to find a program that does what i need. So i decided to write something myself, the code including an ebuild is available here: https://code.pa4wdh.nl.eu.org/tools/cpu ... req/about/

I hope it helps someone else too . Feedback is welcome of course.

[Zucca]

Any plans to submit an ebuild to ::guru? ;)

[pa4wdh]

So far I don't have any plans to do that.

[Zucca]

So maybe I'll create one for my overlay. ;)

EDIT: You seem to have a gentoo/ directory on the git repository, which contains ebuilds for it, like https://code.pa4wdh.nl.eu.org/tools/cpu ... 0.3.ebuild

Do you have a dedicated overlay for these?

[pa4wdh]

I indeed made an ebuild, it's what i use to install it on my own PC

For personal use i simply add the ebulid to an existing local overlay, I don't have any other (published) overlay dedicated to this. Feel free to add it to your own overlay.

[Zucca]

Feel free to add it to your own overlay.

Will do!

[Zucca]

Done.

[NichtDerHans]

Could you give an example of a start command with parameters? Iam not sure if I do it right.

[pa4wdh]

On my system it's running with these parameters:

Code: Select all

/usr/sbin/cputemp2maxfreq -l kmsg -t 70

Which means it will log to /dev/kmesg (which appears in dmesg) and it will start scaling down the CPU frequency when the temperature is above 70 degrees Celsius.

I expect the defaults to work most of the time, but i'm not sure since i've only used it on my own PC.

@Zucca: Thanks!

[Zucca]

Hm. Looks like my system reports CPU temperature on a another location: /sys/class/hwmon/hwmon4/temp1_input. That's not a problem, but the value got from there is in millicelcius. So I tried to set the upper temperature limit as millicelcius... Nope.

Code: Select all

Invalid current tempature reported by CPU, exiting

... is what I get in every case. (Note the typo there. ;) )

@pa4wdh, a crude solution to this would be to detect if the temperature value has length from 1 to 3, then it's celcius, if its length is from 4 to 6 then it's in millicelcius.
I don't think any driver reports temperature with "°C" extension, but if some does, then parsing out only numbers might also be needed.

[pa4wdh]

As far as i'm aware all temperatures in sysfs are reported in millicelsius, the -t parameter given to my daemon gets multiplied by 1000 to facilitate this so you should be fine by just pointing -i to the right location.

And thanks for pointing out the typo

[Zucca]

Ah. My problems were because of a silly typo.
Because the daemon failed to start at first, I then ran its init script with --debug, and copied the command line...

Code: Select all

/usr/sbin/cputemp2maxfreq -- -l syslog ...

The double dashes (which are needed by start-stop-daemon) there caused the problem.
The daemon is now running. I'll start testing.

[pa4wdh]

Good you found that. I'm interested to hear how it works for you.

[NichtDerHans]

Intel i7-1165G7

There is no governor conservative. So I start with:

Code: Select all

# ./cputemp2maxfreq -g performance
2024-07-24 20:09:16: cputemp2maxfreq version 0.3-ca43307 (master), buildtime Jul 21 2024 20:48:14
2024-07-24 20:09:16: Configuration:
2024-07-24 20:09:16: Governor: performance
2024-07-24 20:09:16: Temperature: 70000
2024-07-24 20:09:16: Temp input: /sys/devices/virtual/thermal/thermal_zone0/temp
2024-07-24 20:09:16: Frequency step: 100000
2024-07-24 20:09:16: Fallback frquency: 2000000
2024-07-24 20:09:16: Interval: 10
2024-07-24 20:09:16: Logger: stdout (0x55f580ee9b24)
2024-07-24 20:09:16: Log measurement data: 0
2024-07-24 20:09:16: CSV Log file: Disabled
2024-07-24 20:09:16: Use unix timestamps: 0
2024-07-24 20:09:16: CPU data:
2024-07-24 20:09:16: Minimum frequency: 400000
2024-07-24 20:09:16: Maximum frequency: 4700000
2024-07-24 20:09:16: Scaling maximum frequency: 400000
2024-07-24 20:09:16: Transition Latency: 0
2024-07-24 20:09:16: Increase scaling_max_freq to 2800000
2024-07-24 20:09:16: Failed to set scaling_max_freq, exiting
2024-07-24 20:09:16: Set scaling frequency to CPU's minimum frequency
#

How can I help?

[logrusx]

Intel i7-1165G7

There is no governor conservative.

You should enable it in the kernel. Performance however should work just as well as conservative, I think. Just be careful to select the correct temp input, which you haven't done:

Code: Select all

2024-07-24 20:09:16: Temp input: /sys/devices/virtual/thermal/thermal_zone0/temp

It selected the same input for me which I don't know what it is, but it doesn't reflect the real temperature of mu CPU.

Best Regards,
Georgi

[logrusx]

@pa4wdh, can you explain this:

Code: Select all

2024-07-24 21:37:22: Increase scaling_max_freq to 4463000
2024-07-24 21:38:02: Decrease scaling_max_freq to 4463000
2024-07-24 21:38:43: Decrease scaling_max_freq to 4463000
2024-07-24 21:39:43: Decrease scaling_max_freq to 4063000

Only the first and the last line actually change the max frequency.

Best Regards,
Georgi

[pa4wdh]

@NichtDerHans:
The performance governor should also work. The conservative governor makes the effect bigger because it scales the CPU frequency down then the load is low, allowing your CPU to cool down faster.

Your transition delay (read from /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency) is reported as 0 which is odd. It should be the delay between setting a frequency and it physically being done in the CPU. As a safety measure the daemon sets the new frequency, waits for the transition delay, reads the frequency again, and expects the readout to be the frequency it set. For example on my system this delay is 20000 (20ms).
Since in your case the delay is reported to be 0, the check is done immediately which most likely is too short for anything to happen.

I could make a new parameter so you can supply your own value for the delay.

@logrusx:
That log odd indeed. The if statements use higher/lower than, so they shouldn't trigger when current value==new value. Are you using any special CFLAGS?
Maybe running with debug info gives more insight in what's happening. That would require manual compiling (not via portage) and changing DEBUG_ALL to 3 in debug.h. Is that something you can do?

[logrusx]

Code: Select all

grep FLAGS /etc/portage/make.conf
#COMMON_FLAGS="-march=core2 -O2 -pipe" #          #
#CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"   #
COMMON_FLAGS="-march=native -pipe -O2"                                                                                             #
CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3"                 #
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

The commented parts are for distcc for my old computer, this one is Ryzen 7 5800H in a laptop. Your daemon caught my attention because it can help avoid switching power profiles in the summer and keep the CPU temperature of 80 degrees Celsius while in the max performance profile. It helps keep the fans quieter as well. It also allows for optimal performance depending on the ambient temperature. I wish I had figured that out earlier.

I wonder however how that would affect power consumption when not under heavy load. Maybe it's a good idea to only run it when compiling.

Best Regards,
Georgi

[pa4wdh]

Your reply was faster than my edit on my message, so to be sure i'm repeating my edit here:
Maybe running with debug info gives more insight in what's happening. That would require manual compiling (not via portage) and changing DEBUG_ALL to 3 in debug.h. Is that something you can do?

[logrusx]

Maybe running with debug info gives more insight in what's happening. That would require manual compiling (not via portage) and changing DEBUG_ALL to 3 in debug.h. Is that something you can do?

I'm actually running it outside of portage and I'll do it tomorrow and will get back to you.

p.s. I made a few edits too.

Best Regards,
Georgi

[logrusx]

//link to crappy file sharing service removed

[pa4wdh]

I've made a new (0.4) version of the daemon which includes a parameter to manually set the transition delay.
@NichtDerHans: This should help with you setup. Valid values are 0...100000, 50000 should be a safe first try. When it's too low you'll see it exit immediately (just like it did now), and increase by 10000 until it works.

@logrusx:
Thanks for your effort to collect the logs. Unfortunately the website you link to redirects me to very shady websites which i don't like to visit. Could you share your log via a different service? (or simply post the relevant part of it here?)

[logrusx]

@logrusx:
Thanks for your effort to collect the logs. Unfortunately the website you link to redirects me to very shady websites which i don't like to visit. Could you share your log via a different service? (or simply post the relevant part of it here?)

I'm sorry, I didn't check if the site is OK. I don't know what is relevant, this is excessive output to me, I hope you can find it out: https://drive.google.com/file/d/1MA_L8I ... sp=sharing

I hope this link works.

Best Regards,
Georgi

[Zucca]

I've found out that most of the time, when submitting long logs, one can pipe the log trough a compressor and some base[N] encoder, so that the log file size does not exceed the pastebin size limit.

Code: Select all

zstd -kc /path/to/big.log | base64 | wgetpaste

... then users who want to view it:

Code: Select all

curl -s <pastebin_url> | base64 -d | zstd -kd | less

(Something like this should maybe implemented in wgetpaste...)