4 ms·

echo hw.perfpolicy="auto" >> /etc/sysctl.conf What's the big deal, there are often changes, sometimes inconvenient, sometimes breaking changes, requiring a con

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.

Macha 4y ago
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.
KronisLV 4y ago
> 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/ https://www.jason.af/defaults-matter/
- discardedrefuse 4y ago
  > 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.
- throwawayboise 4y ago
  > 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.
  - KronisLV 4y ago
    > 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?
daneel_w 4y ago
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.
gigatexal 4y ago
> 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?
- throwawayboise 4y ago
  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

Macha 4y ago

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.

KronisLV 4y ago

> 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/ https://www.jason.af/defaults-matter/

discardedrefuse 4y ago
> 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.
throwawayboise 4y ago
> 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.
- KronisLV 4y ago
  > 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?

daneel_w 4y ago

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.

gigatexal 4y ago

> 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?

throwawayboise 4y ago
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