3 ms·

Also, one thing I've always wondered: why do people want to use hwmon to set fan RPMs? (Or really, why do this from userspace at all?) It seems inherently dange

Also, one thing I've always wondered: why do people want to use hwmon to set fan RPMs? (Or really, why do this from userspace at all?) It seems inherently dangerous to me, as you're asking a process who might not receive CPU time for whatever reasons from the very much not realtime OS to control a fan; if the current RPM is too low, and the system starts generating heat, but the fan controlling process doesn't get CPU time … then what happens? It seems to me you want fans controlled with something dedicated to it. The other thing I don't get is all the plethora of options my motherboard gives me to set fans only to fixed RPMs. Am I crazy in that I want the fan to be controlled by heat? (More heat => more RPMs. Keep the system cool, but if there isn't much thermal load, spin the fans down and reduce the noise?) But by fixing an RPM, it seems the only valid input is "100%"; anything else could be too low under stressful conditions. I could also have a cheap motherboard. (I definitely won't be purchasing from this manufacturer again, and the motherboard does have other severe quality issues…)

MaulingMonkey 4y ago
> It seems inherently dangerous to me In the old days, it kinda was - at least to your hardware. Then people realized that blowing up components because a fan failed, or became unplugged, or a filter clogged with dust, maybe wasn't a great user experience and/or caused more in-warranty returns that required replacing hardware ($$expensive$$!), and implemented thermal throttling and thermal cutoffs. Nearly two decades ago at this point, I helped a friend diagnose his computer randomly turning off. It turned out to be a CPU fan unplugged itself, causing overheating to trigger a thermal cutoff. No other apparent harm done. Fans aren't the only means of limiting heat: slowing stuff down and turning stuff off also works. And it turns out users sometimes would rather stuff run slow than run loud, and maybe your crappy motherboard vendor shouldn't be writing a ton of code running in kernel space - with all the potential stability and security issues that might entail - for whatever network-connected bloatware syncs your RGB lighting and fan settings to the cloud. And they will do exactly that, if that's what's required to give their customers what they want. Just exposing fan RPMs to userspace might be far less dangerous.
- deathanatos 4y ago
  > and maybe your crappy motherboard vendor shouldn't be writing a ton of code running in kernel space - with all the potential stability and security issues that might entail This wasn't the suggestion I was making. I was suggesting that the motherboard, itself, should be controlling the fan RPMs (or should at least provide such a mode). I don't feel like taking a temperature input, and mapping that to an RPM output should take much circuitry at all, but it that (somehow) required a full-blown CPU, I was thinking a (very small) auxiliary chip, dedicated to the task. But yes, if you're going to do it on the main CPU, then in userspace. But now you incur all the problems I mentioned in the original comment, some of which can exhibit death spirals: CPU has to throttle due to heat, meaning less CPU time, meaning it will take longer to get to the code responsible for alleviating the problem of heat by notching the RPM up! In the worse case, you hit the CPU's critical trip point before the problem can be brought under control.
  - wtallis 4y ago
    On typical desktop motherboards, the Super IO chip handles all the temperature monitoring and fan control. Those chips usually have a few modes to configure some very simple control system for mapping temperature inputs to fan speed outputs (never anything as advanced as a PID controller). The main problem is that the Super IO only has access to the temperature sensors on the motherboard itself, and on the CPU (these days, through PECI). There's no standard way for the Super IO to do out of band monitoring of temperatures on your GPU or storage drives, so if you want those to affect fan speeds you need to implement it in software. Servers typically have BMCs controlling fans, and even Apple's x86 machines have their SMC; in both cases you typically see a more thorough monitoring of component temperatures, configured out of the box with a proper awareness of which fans are blowing across which components. But that stuff doesn't trickle down to the build your own desktop market.
    - deathanatos 4y ago
      Hmm. I guess I have no idea how this chip interfaces with the kernel then? The only knobs that seem to be documented to exist ever are direct RPM controls for manual control. I know it's possible (despite the insistence to the contrary on the other thread), as basically every laptop does it. Only do desktops seem to struggle with this concept.
toast0 4y ago
> why do people want to use hwmon to set fan RPMs? (Or really, why do this from userspace at all?) Some people want to have a mode switch; normal use should be silent/quiet, but when you know you're going to do something big (game, big compile, etc), fix the fans at full so the noise is consistent and cooling is best. (the cooler the chip, the more the boost) Some people have no good options from the system firmware, and getting _something_ configurable is better. I've run on systems where I couldn't tell the system to actually run the fan, so things would get hot and throttle. Userspace configurability is better than nothing. This tends to be a bigger issue on things that are sold as a whole computer, like laptops, and small formfactor things (which are often pretty much laptops without a battery and built in user interface devices) but also some name brand desktops. My recent motherboards all seem to have a pretty nice fan configuration tool. Presets for quiet/performance/full speed, and a simple graph based UI to set % by temperature. Most of the fan headers can be set to follow the cpu temperature or the system temperature. When you buy the nice Noctua fans, they also ship 'low noise adapters' that I assume drop the voltage and limit the maximum RPMs and limit noise. Depending on your overall cooling design, that can be reasonable or asking for trouble.
- deathanatos 4y ago
  > Some people want to have a mode switch; normal use should be silent/quiet, but when you know you're going to do something big (game, big compile, etc), fix the fans at full so the noise is consistent and cooling is best. (the cooler the chip, the more the boost) Yeah, I don't doubt someone is like that … I'd just rather it be automatic. > My recent motherboards all seem to have a pretty nice fan configuration tool. Mine has a "flashy" tool, I would say. Certainly looks pretty, but again, it's all constant RPM options. As I lament in the other thread, this is something that would differentiate boards at time of purchase, but no mobo manufacturers marketing dept. seems to have it's shit together enough to get such a differentiation across to the consumer. Instead the focus seems to be completely on the aesthetics of how the board looks. And again, I've chalked this up to having chosen poorly. But there-in is the problem: assuming I chose poorly, assuming some mobos do support sane defaults/fetures … how do I end up finding and purchasing one of those? Any knowledge I acquire during a purchase is useless the next time around, given the constant product churn HW manufacturers nonsensically do.
dankamongmen 4y ago
you might want to use different algorithms for automatic control than those exposed through the motherboard firmware, which are pretty much limited to either constant, manual setpoints (usually with extrapolation), and a linear temp-to-rpm curve (ideally with different possible sources). if you look at my linked Counterforce project, i believe there to be value beyond these simplest management schemes. we'll see.

MaulingMonkey 4y ago

> It seems inherently dangerous to me In the old days, it kinda was - at least to your hardware. Then people realized that blowing up components because a fan failed, or became unplugged, or a filter clogged with dust, maybe wasn't a great user experience and/or caused more in-warranty returns that required replacing hardware ($$expensive$$!), and implemented thermal throttling and thermal cutoffs. Nearly two decades ago at this point, I helped a friend diagnose his computer randomly turning off. It turned out to be a CPU fan unplugged itself, causing overheating to trigger a thermal cutoff. No other apparent harm done. Fans aren't the only means of limiting heat: slowing stuff down and turning stuff off also works. And it turns out users sometimes would rather stuff run slow than run loud, and maybe your crappy motherboard vendor shouldn't be writing a ton of code running in kernel space - with all the potential stability and security issues that might entail - for whatever network-connected bloatware syncs your RGB lighting and fan settings to the cloud. And they will do exactly that, if that's what's required to give their customers what they want. Just exposing fan RPMs to userspace might be far less dangerous.

deathanatos 4y ago
> and maybe your crappy motherboard vendor shouldn't be writing a ton of code running in kernel space - with all the potential stability and security issues that might entail This wasn't the suggestion I was making. I was suggesting that the motherboard, itself, should be controlling the fan RPMs (or should at least provide such a mode). I don't feel like taking a temperature input, and mapping that to an RPM output should take much circuitry at all, but it that (somehow) required a full-blown CPU, I was thinking a (very small) auxiliary chip, dedicated to the task. But yes, if you're going to do it on the main CPU, then in userspace. But now you incur all the problems I mentioned in the original comment, some of which can exhibit death spirals: CPU has to throttle due to heat, meaning less CPU time, meaning it will take longer to get to the code responsible for alleviating the problem of heat by notching the RPM up! In the worse case, you hit the CPU's critical trip point before the problem can be brought under control.
- wtallis 4y ago
  On typical desktop motherboards, the Super IO chip handles all the temperature monitoring and fan control. Those chips usually have a few modes to configure some very simple control system for mapping temperature inputs to fan speed outputs (never anything as advanced as a PID controller). The main problem is that the Super IO only has access to the temperature sensors on the motherboard itself, and on the CPU (these days, through PECI). There's no standard way for the Super IO to do out of band monitoring of temperatures on your GPU or storage drives, so if you want those to affect fan speeds you need to implement it in software. Servers typically have BMCs controlling fans, and even Apple's x86 machines have their SMC; in both cases you typically see a more thorough monitoring of component temperatures, configured out of the box with a proper awareness of which fans are blowing across which components. But that stuff doesn't trickle down to the build your own desktop market.
  - deathanatos 4y ago
    Hmm. I guess I have no idea how this chip interfaces with the kernel then? The only knobs that seem to be documented to exist ever are direct RPM controls for manual control. I know it's possible (despite the insistence to the contrary on the other thread), as basically every laptop does it. Only do desktops seem to struggle with this concept.

toast0 4y ago

> why do people want to use hwmon to set fan RPMs? (Or really, why do this from userspace at all?) Some people want to have a mode switch; normal use should be silent/quiet, but when you know you're going to do something big (game, big compile, etc), fix the fans at full so the noise is consistent and cooling is best. (the cooler the chip, the more the boost) Some people have no good options from the system firmware, and getting _something_ configurable is better. I've run on systems where I couldn't tell the system to actually run the fan, so things would get hot and throttle. Userspace configurability is better than nothing. This tends to be a bigger issue on things that are sold as a whole computer, like laptops, and small formfactor things (which are often pretty much laptops without a battery and built in user interface devices) but also some name brand desktops. My recent motherboards all seem to have a pretty nice fan configuration tool. Presets for quiet/performance/full speed, and a simple graph based UI to set % by temperature. Most of the fan headers can be set to follow the cpu temperature or the system temperature. When you buy the nice Noctua fans, they also ship 'low noise adapters' that I assume drop the voltage and limit the maximum RPMs and limit noise. Depending on your overall cooling design, that can be reasonable or asking for trouble.

deathanatos 4y ago
> Some people want to have a mode switch; normal use should be silent/quiet, but when you know you're going to do something big (game, big compile, etc), fix the fans at full so the noise is consistent and cooling is best. (the cooler the chip, the more the boost) Yeah, I don't doubt someone is like that … I'd just rather it be automatic. > My recent motherboards all seem to have a pretty nice fan configuration tool. Mine has a "flashy" tool, I would say. Certainly looks pretty, but again, it's all constant RPM options. As I lament in the other thread, this is something that would differentiate boards at time of purchase, but no mobo manufacturers marketing dept. seems to have it's shit together enough to get such a differentiation across to the consumer. Instead the focus seems to be completely on the aesthetics of how the board looks. And again, I've chalked this up to having chosen poorly. But there-in is the problem: assuming I chose poorly, assuming some mobos do support sane defaults/fetures … how do I end up finding and purchasing one of those? Any knowledge I acquire during a purchase is useless the next time around, given the constant product churn HW manufacturers nonsensically do.

dankamongmen 4y ago

you might want to use different algorithms for automatic control than those exposed through the motherboard firmware, which are pretty much limited to either constant, manual setpoints (usually with extrapolation), and a linear temp-to-rpm curve (ideally with different possible sources). if you look at my linked Counterforce project, i believe there to be value beyond these simplest management schemes. we'll see.