OpenBSD 7.1: fan noise and high temperature solution | Hacker News Reader

OpenBSD 7.1: fan noise and high temperature solution

dataswamp.org

50 pointshucste14 comments

Power Management has always been tricky in how you approach it from a defaults perspective. For example, in ...

Servers - you most likely want to prioritize always having max performance (in lieu of power/heat).

Laptops, you probably want to dynamically adjust performance since you're in physical contact with the device that's producing the heat.

Desktops, it's a bit unknown what the user might wants to prioritize (is it power efficiency, is it max perform, or a hybrid).

Microsoft got this right decades ago and just made it a togglable OS option for the user to decide.

IMO servers are bit more tricky, these days there is a big advantage in operating in the best power/perf/watt window - the limits are in DC power and cooling

Kinda drives me nuts when OEMs in windows decide they don't want to integrate with the Window power manager and instead want to offer their own take. Granted that seems to have mostly gone away in Win 10 and 11.

GNU/Linux too since Cpufreq. It's the DE's task to set that graphically to the user. Nothing difficult, at all.

Under OpenBSD, apmd(8) handled that until now. https://man.openbsd.org/apmd

This change, made seemingly entirely on Theo's whim, has rightfully caused quite some criticism on the mailing lists and on IRC. I'm not sure if it ever crossed his mind exactly how much more fan noise, and how many more megawatt-hours of wasted power (and money spent on electricity bills), this will cause globally for the collective user base. Very poor choice of anti-ecology. It offsets the benefits and the work that has gone into making computers and operating systems power-efficient.

echo hw.perfpolicy="auto" >> /etc/sysctl.conf

What's the big deal, there are often changes, sometimes inconvenient, sometimes breaking changes, requiring a configuration file change or software update. This is true of any operating system update or upgrade.

> What's the big deal, there are often changes, sometimes inconvenient, sometimes breaking changes, requiring a configuration file change or software update.

I think some might suggest that the defaults matter a lot.

> However, it may doesn't throttle well for some users, resulting in huge power usage even when idle, heat from the CPU and also fan noise.

While the crowd that uses OpenBSD might be crafty enough to look up and apply solutions, this happening in any mainstream OS would be unacceptable, since many simply wouldn't know how to change the setting, or wouldn't even be aware that there's a setting to change in the first place.

And what would the consequences be if tens to hundreds of millions of devices out there suddenly started wasting lots of electricity and ran in a mode that could cause the CPUs to fail more quickly?

Here's a nice article on the topic of defaults: https://www.jason.af/defaults-matter/

> this happening in any mainstream OS would be unacceptable, since many simply wouldn't know how to change the setting, or wouldn't even be aware that there's a setting to change in the first place.

Last year I tried to run FreeBSD on a HP DL380 G7 (old-ish enterprise server). After install, all the fans were spinning at ludicrous speeds. Funny thing about these HP servers; the fans will spin like this if you put non-HP hardware components in them. I don't have non-HP components, so I never had the fan issue prior to FreeBSD. But because the issue was so common, searching the web kept turning up crazy solutions using resistors and such. I gave up and put Alpine Linux on there instead. Alpine worked great.

Months later, I went back and tried FreeBSD again. This time I had stumbled across a FreeBSD specific fix for the fan: sysctl hw.acpi.cpu.cx_lowest=C3

That was it; a C state setting. I had to learn about C states, powerd and Intel SpeedStep before I could do anything with FreeBSD on that server. No power management. But... we get a mail server?

Yeah, I would say defaults do matter.

> While the crowd that uses OpenBSD might be crafty enough to look up and apply solutions, this happening in any mainstream OS would be unacceptable

OpenBSD expects that its users will look up and apply solutions.

They do not have a goal to be a mainstream OS.

> OpenBSD expects that its users will look up and apply solutions.

That is fine and all, but consider the following:

  - if a solution is needed, that means that there's a problem; why should an update knowingly introduce a problem?
  - caring about the environmental impact/load on the hardware isn't mutually exclusive with being knowledgeable and able to apply solutions; shouldn't the more conservative/environmentally friendly option be the default setting?

Third line of the article:

> As the usual "automatic" frequency scheduling mode is no longer available, I wrote a simple utility to manage the frequency when the system is plugged to the wall, I took the opportunity to improve it, giving better performance than the previous automatic mode, but also giving more battery life when using on a laptop on battery.

> echo hw.perfpolicy="auto" >> /etc/sysctl.conf

if the above worked (I'm not a openbsd user really) then why would the author need to create the utility that created this post?

From the author's project page, "This is mostly a playground project so I can experiment with CPU frequency scheduling"

It seems one advantage is that it offers more control and settings for those who want it. E.g. options for:

-d downstepfrequency sets the steps removed every cycle when decaying, default to 100

-i inertia sets the number of cycles after which the frequency will decay, 0 is the default

-m maxfrequency sets the maximum frequency the CPU can reach in percent, 100% is default

-l minfrequency sets the minimum frequency the CPU must be lowered to, 0% is default

-r threshold sets the CPU usage in % that will trigger the frequency increase, 30% is the default

-s stepfrequency sets the percent of frequency added every cycle when increasing, 10% is default

-t timefreq sets the milliseconds between each poll, 300 is the default

-T maxtemperature sets the temperature threshold under which the maximum frequency will be temporary lowered until the CPU cools down

hw.perfpolicy is as of 7.1 effectively hard-coded to "high" in the kernel when the machine is on mains power, forcing the CPU to always run at maximum available frequency even when idling. This is a big deal.

Reply on news.ycombinator.com