CPU speed throttled (hwpstate_intel)

A

ahhyes

Hi All,

I need some guidance/suggestions. Just spun up a fresh desktop system with 14.0-RELEASE (amd64). I have noticed that the CPU frequency is allover the place - Its very reminiscent of when Linux has its cpu govenor set to powersaving mode instead of performance (which just lets all cores run at full speed at all the time, which is what I am trying to achieve here).

Some info:
root@bsd-desktop:~ # sysctl dev.cpufreq.0.freq_driver
dev.cpufreq.0.freq_driver: hwpstate_intel0

root@bsd-desktop:~ # sysctl dev.cpu.0.freq_levels dev.cpu.0.freq
dev.cpu.0.freq_levels: 3700/-1
dev.cpu.0.freq: 1197

I cant for the life of me find a way to stop the frequency across all the cores from throttling down all the time.

I have looked at the handbook article https://docs.freebsd.org/en/books/handbook/config/#hwpstate_intel and the manpage for HWPSTATE_INTEL(4) and I am still none the wiser..

I have tried setting dev.hwpstate_intel.0.epp to zero as the man page indicates it SHOULD set a preference for performance, but when checking dev.cpu.0.freq to verify the result the frequency is allover the place and dipping down all the way to 1200 frequently (which makes me believe its having no effect).

What am I doing wrong?
 
powerd is apparently obsolete and not needed when using hwpstate_intel -- so I have not enabled it.
 
Based on the small section here, it seems:

On systems where hwpstate_intel0: <Intel Speed Shift> on cpu0 appears in /var/run/dmesg.boot, it is recommended to set machdep.hwpstate_pkg_ctrl=0 using sysctl and adjust the values for dev.hwpstate_intel.%d.epp between 0 and 100 depending on the choice of performance vs efficiency desired.
Click to expand...

So disabling *.hwpstate_pkg_ctrl, is needed first and then you should be able to manually set it via the *.epp sysctl.

Looking at mine, I haven't really touched that and it seems to be quite stable (seems locked at 50) but might be worth a shot.
 
Looking at my CPU, it is an i9-10900X - some digging tells me that this CPU doesn't support Intel speed shift (too old), I suspect this one to be using "Intel SpeedStep Technology" - will setting the epp sysctl's for CPU's that dont have speed shift functionality still work?
 
I tried machdep.hwpstate_pkg_ctrl=0 in /boot/loader.conf and this did allow individual core control via the epp sysctl, but the behavior is still not what I was expecting - I set the value to zero which should favor performance, and it made no difference, same behavior (with the exception it allowed a higher overall frequency to be achieved, but would still throttle it back whenever it wanted).

I do see this in the dmesg:
Code: 
hwpstate_intel0: <Intel Speed Shift> numa-domain 0 on cpu0

I am surprised since I thought my CPU was too old for Speed Shift and that came later in CPU's (my i9 was released in 2019).

The only thing that seemed to fix the wandering CPU speeds was to disable the hwpstate_intel driver entirely by adding hint.hwpstate_intel.0.disabled=1 to my /boot/loader.conf - now it looks how I want:

Code: 
dev.cpu.19.freq: 3701
dev.cpu.17.freq: 3701
dev.cpu.15.freq: 3701
dev.cpu.13.freq: 3701
dev.cpu.11.freq: 3701
dev.cpu.9.freq: 3701
dev.cpu.7.freq: 3701
dev.cpu.5.freq: 3701
dev.cpu.3.freq: 3701
dev.cpu.1.freq: 3701
dev.cpu.18.freq: 3701
dev.cpu.16.freq: 3701
dev.cpu.14.freq: 3701
dev.cpu.12.freq: 3701
dev.cpu.10.freq: 3701
dev.cpu.8.freq: 3701
dev.cpu.6.freq: 3701
dev.cpu.4.freq: 3701
dev.cpu.2.freq: 3701
dev.cpu.0.freq: 3701

It is stable at 3.7Ghz and not wandering around allover the place.. Disabling that driver wasn't really the direction I hoped to go, but nothing else seemed to work for me.
 
ahhyes said:
I tried machdep.hwpstate_pkg_ctrl=0 in /boot/loader.conf and this did allow individual core control via the epp sysctl, but the behavior is still not what I was expecting - I set the value to zero which should favor performance, and it made no difference, same behavior (with the exception it allowed a higher overall frequency to be achieved, but would still throttle it back whenever it wanted).
Click to expand...

Presumably because it's smart enough not to waste power and heat while not doing useful work, that is without sufficient load to need higher than idle performance.

ahhyes said:
The only thing that seemed to fix the wandering CPU speeds was to disable the hwpstate_intel driver entirely by adding hint.hwpstate_intel.0.disabled=1 to my /boot/loader.conf - now it looks how I want:

Code: 
dev.cpu.19.freq: 3701
[ ... ]
dev.cpu.0.freq: 3701
Click to expand...

Looks orderly, sure.

ahhyes said:
It is stable at 3.7Ghz and not wandering around allover the place.. Disabling that driver wasn't really the direction I hoped to go, but nothing else seemed to work for me.
Click to expand...

What I don't understand is why you would want to run 20 CPUs at 3.7GHz unless there was concurrently a great deal of useful work for them to do?

You may find it informative to add to /boot/loader.conf:
coretemp_load="YES"
and/or immediately run:
# kldload coretemp
then periodically check
% sysctl dev.cpu | grep temperature
to see how much heat it's generating and thus power wasted, compared to idle.

And for what advantage? A microsecond or two quicker response, at best, to sudden real load?
 
smithi said:
And for what advantage? A microsecond or two quicker response, at best, to sudden real load?
Click to expand...
If this had been a laptop machine, I most certainly would not have done what I did, since it would shorten battery life significantly. I dual boot this system and have Linux on the other drive, it too defaulted to the same powersaving scheme and the problem it caused were in certain multimedia applications and some games, where the it would cause micro stutters/pauses while the frequency would suddenly need to scale up on demand.

But I do agree with you, from a power efficiency standpoint it scores a -10/10.
 
ahhyes said:
If this had been a laptop machine, I most certainly would not have done what I did, since it would shorten battery life significantly.
Click to expand...

Yes - and cook your lap well.

ahhyes said:
I dual boot this system and have Linux on the other drive, it too defaulted to the same powersaving scheme and the problem it caused were in certain multimedia applications and some games, where the it would cause micro stutters/pauses while the frequency would suddenly need to scale up on demand.
Click to expand...

Have you confirmed that these same issues were also evident in FreeBSD, before the change?

ahhyes said:
But I do agree with you, from a power efficiency standpoint it scores a -10/10.
Click to expand...

I was also considering other effects of heat, such as accelerated shrinkage of heatsink compounds, possible shortened life of some capacitors, etc - but in a well-ventilated box that may be of less concern.

Certainly should get along ok!
 
smithi said:
You may find it informative to add to /boot/loader.conf:
coretemp_load="YES"
and/or immediately run:
# kldload coretemp
then periodically check
% sysctl dev.cpu | grep temperature
to see how much heat it's generating and thus power wasted, compared to idle.
Click to expand...

Thank you for that tip! I have added that.

Here are the results with a 4k video playing in full screen in firefox (which is using about 160-220% cpu according to top)

Screenshot_20231224_000141.png


Seems to be holding up pretty well (I have a decent CPU cooler) and the system is quite responsive!
 
One thing I have noticed with recent CPUs is that the CPU frequency doesn't really alter the power requirement or the temperature as much as it used to.

As to the reverse of that, OpenBSD downscales my CPU just as much as FreeBSD on the same machine but ends up a good 4W more expensive in terms of power and is considerably warmer. So there seems to be more to it than frequency.

So really, running at full frequency might not be such a bad compromise.
 
You must log in or register to reply here.
Back
Top