Throttle computing based on fan speeds

[davidpanderson]

Volunteers often stop running BOINC if it makes their fans go to high speed.

By default, the client should throttle computation in a way that avoids this.

[Ferroin]

There's not really any reliable way to do this. On pretty much every platform BOINC runs on, you have no guarantee that you can even retrieve the fan speed, let alone that what you get back is accurate or what the max speed is.

Additionally, the primary issue for most people is actually noise (many people don't realize quite how bad OEM cooling systems are, let alone the crap that is GPU cooling, and it's all made worse by the push for smaller systems and the refusal by vendors to use cage blowers (which are much quieter than equivalently sized axial blowers)), and you can't correlate speed to the amount of noise generated reliably at all because:

• You don't know how big the fans are, how the blades are shaped, and whether it's an axial or cage blower, all of which are much more important to the total noise generated than the fan speed. For example, a cage blower running at 3000 RPM will almost always be quieter than an axial blower of the same size running at the same speed.
• Most fans don't exhibit a linear correlation between rotational speed and noise, and some even run louder below a certain speed than they do at full speed (I actually have some like this in my home server system, they are quietest between roughly 1100 and 1500 RPM, below that the bearings destabilize a bit and make noise, above that they generate lots of turbulence and make noise).

[Ageless93]

Isn't this a replica duplicate of #1378, #1379 and #1474?

[SETIguy]

Yes, this does duplicate 1378/1379, and it probably requires a device driver or additional software to be installed on windows (i.e. speedfan, CPU-z, GPU-z). On newer linux kernels many temperature monitors are in the sysfs file system. The trick is finding the right monitors.

I've been meaning to do a linux implementation of CPU temperature monitoring, but haven't had a chance yet.

On Mon, Nov 6, 2017 at 7:21 AM, Jord van der Elst notifications@github.com wrote:

Isn't this a replica of #1378 https://github.com/BOINC/boinc/issues/1378,

1379 https://github.com/BOINC/boinc/issues/1379 and #1474

https://github.com/BOINC/boinc/issues/1474?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2215#issuecomment-342180820, or mute the thread https://github.com/notifications/unsubscribe-auth/AKXcskuAx5MQq-JVXQz-_Con7jxj2TUJks5szyPngaJpZM4QSxUG .

-- Eric Korpela korpela@ssl.berkeley.edu AST:7731^29u18e3

[davidpanderson]

Uh, CPU temp and fan speed are not the same. Fan speed is the critical thing because users notice it

[Ferroin]

And unlike fan speed, you actually have some reasonable level of control over CPU temperature (and that has practical applications beyond limiting fan speed, for example the battery temperature checking on Android).

It's also a lot harder to get fan speed reliably than CPU temperature. On Linux at least, CPU temperature reporting is pretty much 100% accurate and reliable on all AMD CPU's since K10 (except Ryzen, because AMD refuses to release the data sheet on how to query the sensor directly), and all Intel CPU's since the original Core series. For fan speed however, you're at the mercy of whatever poorly documented and often not-completely-supported crap the MB manufacturer decides to use for gathering tachometer readings from the fan. I've not seen any non-Ryzen x86 system in the last decade that you couldn't get a CPU temperature from reliably on Linux, but I've also not seen one where you could get the fan speed reliably.

Add on top of that you still have the issues I already pointed out regarding this, and it really starts to look like much more work than it's worth. You are listed as a contributor though, so there's no reason you couldn't try and implement this yourself if you feel so strongly about it, though you may want some form of medication to help retain your sanity once you start delving into the chaos that is fan speed reporting on Linux running on modern systems.

Also, if you're going to be picky, it's the noise, not the fan speed (5000 RPM is still almost silent for the CPU fan on an Intel NUC, but for the fans in most server systems that translates to jet-engine noise levels) that bothers people.

[SETIguy]

(Relplying to David, above) True, but there's no uniform method or conversion to derive fan speeds. At least with CPU temperatures there's a somewhat generic Intel method and a generic AMD method. For fan speeds you'll need a separate method for each motherboard manufacturer/chipset manufacturer combination. Even then there's no guarantee that the fan speed can be read. I've never had a lenovo laptop that supported any method or reading the fan speed It might be better to use CPU temperature as a proxy.

[Iwork4beer]

Fans are strictly related to the temperature, temperature is stricly related to the load over time, it is a chain. Solution is simple, divide 100% by the number of cores in your CPU, test how many of them you can use (I'm assuming that, not all of them) to keep the heat low, and the fans wont go crazy. In my case, it is 50%.

Options > Computing preferences... > Use at most XX % of the CPUs

[davidpanderson]

1) doing this for Windows would be sufficient 2) the temp thresholds for fan speed are configurable. Knowing temp doesn't tell you the fan speed. 3) there are Win programs, probably open source, that show fan speed

[JuhaSointusalo]

On the laptop I'm typing on (HP), HWiNFO lists a ton of different values, around 100 maybe. But fan speed is not one of them. Since HWiNFO doesn't list it I have to assume it just isn't made available to software.

[Iwork4beer]

For example SpeedFan, it shows the fan speed in my PC's but not the laptop, here it shows just the temperature. Maybe only some (better) laptops have a fan speed sensor. In my Lenovo M490 fan speed is strictly related to the temp, I know, that I need to keep the CPU under 68deg to not spin the fan at the maximum speed.

[davidpanderson]

If fan speed is available directly, use it. Otherwise use CPU/GPU temp as a proxy. Do research to find what are typical temp thresholds for high fan speed.

[SETIguy]

Accessing these sensors typically requires a device driver (and the danger that entails) to make the values available to user mode code on windows (hence #1474) . I'm not aware of an open source driver. Maybe the SpeedFan author would be willing to contribute code.

On Mon, Nov 6, 2017 at 1:41 PM, David Anderson notifications@github.com wrote:

If fan speed is available directly, use it. Otherwise use CPU/GPU temp as a proxy. Do research to find what are typical temp thresholds for high fan speed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2215#issuecomment-342296640, or mute the thread https://github.com/notifications/unsubscribe-auth/AKXcssApcA87klWu2I5JenO_l7G8bN1iks5sz3zxgaJpZM4QSxUG .

-- Eric Korpela korpela@ssl.berkeley.edu AST:7731^29u18e3

[CharlieFenton]

I added code over 7 years ago to get the highest CPU temperature on Macs. I don't know if that code is still valid, or how easy it is to get that information across all models and years of Macs. The comment from that code: // Check up to 10 die temperatures (TC0D, TC1D, etc.) and // 10 heatsink temperatures (TCAH, TCBH, etc.) // Returns the highest current CPU temperature as degrees Celsius. // Returns zero if it fails (or on a PowerPC Mac).

[Ferroin]

Being able to limit computation based on temperature in general would be nice. It's not going to solve this issue though, because how temperature correlates to fan speed, and then fan speed to noise, is not something the software itself can reliably figure out (It's perfectly normal for many modern Intel CPU's to run over 70 degrees Celsius in an OEM system without a huge amount of noise, but in a DIY gaming system, running that hot will almost always sound like you're on a airport tarmac), and because the type of people who wouldn't look for ways to limit resource usage to make things quieter are also not likely to look for ways to limit system temperature to make the system quieter.

[tomasbackman]

As many people have mentioned in this issue it is the noise not the actual fan speed that is what most people probably would be interested in controlling. This is very hard to measure directly. But maybe there could be an option for the users to test cpu speeds and listen how much it sounds and then choose according to the result of the test..? Like increasing the cpu in increments and showing a corresponding number to the user. For me maybe the noise at level "50" is acceptable, for somebody else "80" depending on their system and location of computer etc. The actual number does not really matter it should just correspond to cpu usage percentage or similar so that it can be used for setting (cpu) limits. It would also be very nice if this setting could be connected with extra user settings for "when computer in use, allow up to level X" "when not in use allow up to level Y" I will create a separate issue/suggestion describing this.

[KLiKzg]

This has been already done & tested on my systems for some 10+ years. How? Early on, back on SETi@home I have fried out some older GT 240 & GT 440 cards. So I was looking for a solution to that & found freeware program called TThrottle. With it I have managed to even save several card not to overcook, latest being 1050Ti with failed fan. How? Well, TThrottle just limits the highest temp. for GPU & CPU in BOINC environment. So it will limit the heat made by processor, running (throttling) them down in the event of higher temp. Now, that does not make "fan speed constant" or the noise from the fans, but TThrottle can be integrated to work with outside sensors like GPU-Z or HWiNFO or Open Hardware Monitor, some of which can manipulate the fan speeds.

Hope this helps.

[AenBleidd]

At first, this is a 3rdparty solution. Second, it works on Windows only, as far as I see on the website. So this doesn't really fulfill our requirements.

[CharlieFenton]

@KLiKzg thanks for reminding people about the availability of TThrottle; it can accomplish a portion of what this issue seeks. TThrottle has been listed on the BOINC website as an add-on for years. In fact, here is a post about it from 2011 written by @davidpanderson (who created this issue on GitHub.) But as @AenBleidd wrote, it doesn't fulfill the more general intent of this issue.

[KLiKzg]

@CharlieFenton, I agree. But as the solution is available, lets not invent a "hot coffee". Maybe there is a way for implementation TThrottle solution into BOINC? As it works... I agree that it does not have sensor readings for Linux. But Linux has scripts, that can do the same thing - stopping CPU & GPU, when sensors detects too high temperature. So reading sensors in Linux & throttling BOINC could be a solution also for Linux systems (& fan noise).

[AenBleidd]

@KLiKzg, thank you for your feedback. As you can see, this ticket was open more that 6 years ago. This is basically an idea of what can be done by BOINC, and it's not in development yet (and not planned to be developed in the near future). Ideally, BOINC should provide an out-of-the-box solution, that works for all (or almost all) platforms BOINC currently supports. TThrottle is a closed-source solution, and not supported by BOINC in any way. Yes, currently users on Windows can use this application if it fits their needs. When/If we decide to implement such a functionality in BOINC, we will carefully do the research to find the best solution that will works for our users and that won't be to hard to implelemt.

[CharlieFenton]

I agree that it does not have sensor readings for Linux. But Linux has scripts, that can do the same thing

I'm more concerned about Apple computers, which you seem to have overlooked. And Intel processors are becoming increasingly obsolete as Windows PCs, Linux boxes and especially Macs are rapidly switching to arm processors.