Too slow to react to high temperature when CPU is bottlenecked

[brunoais]

I think tccd give itself a low nice value by default maybe even -20 nice.
I'm noticing that, sometimes, tccd takes a long time to react to the CPU getting too hot. The CPU can even reach 100ºC and the fans being at low rpm as if it was 60ºC because the PC forces the CPU to become temporarily bottlenecked and, initially, at max frequency (most heat).
Then tccd takes even longer time to react because the CPU starts heavily thermal throttling to try to deal with the excess heat the fans are not blowing away.

So far, I'm dealing with this by making a script that sets the nice to -15 every second. I think it would be great if tccd would do that much on its own.

[tuxedoxt]

Short answer in the general case: The algorithm uses some filtering to provide "smooth and calm" fan control. This has the effect that it does not react immediately to every little change in temperature, this is by design. Perhaps it could be provided as a parameter in the future.

It could also be more apparent due to a recent sneaky issue on some devices. This should be fixed as of tuxedo-cc-wmi 0.1.5.

Which device is this specifically?

Please let me know if the new version of tuxedo-cc-wmi makes a difference.

[brunoais]

I think it makes sense to apply smoothed fan speed changes. I do believe that filtering isn't always the best way to go when the need is to speed up, though.
If you are interested in my opinion, all temperature values should be used to change fan speed as long as the change is outside ±20ºC or, for urgent temperatures (E.g. >90ºC) acting with immediate reaction when the need is to speed up. Inside that interval, which is the norm for CPU work, whatever is done now works well. That's my opinion.

However, in my case, the default algorithm does a nice job in all situations as long as I give tccd a nice of less than -10, as a workaround.

I own a Clevo N850.

[xenon205]

Hi,
My Clevo P670RS is overheating when using Tuxedo CC . Idle temps are around 60*C and when i lunch games in a minute diod starts blinking indicating overheating and then shutdown.
I was using custom profile with fan's set on highest level.
Max fan speed was around 70%.
I have 3 fan's inside of my device. Maybe one of them wasn't running . Idk.
When You add simple fan curve manual setting i will try again but for now it;s a no go app.

[brunoais]

I experimented with my workaround turned off since a few days:

@tuxedoxt I just got another CPU emergency shutdown because tccd at 0 nice reacted too late to order a fan speed up.
I was doing encoding work using ffmpeg from some time of complete standstill in temperatures and fans (CPU at ~50ºC and GPU at ~45ºC).
Then I try to run ffmpeg, leading to a very high CPU usage at 0 Nice.
At ~3 seconds of ordering the encode, I could notice changing windows was starting not to respond and I could notice the fans were not speeding up.
At ~4 seconds of ordering the encode, I ordered a full blast on the fans Fn+1.
At ~4.1 seconds of ordering the encode, emergency shutdown happened; the fans were still ramping up

At no point in those 4 seconds I heard the fans blowing beyond low (almost silent) rpm.

I recommend that tccd should run at a RT priority class and should not do all the "smooth" ramp-up in fan speed when the temperatures are above (in my PC's CPU case) 90ºC. In my case, I'm sure it reached the 105ºC and got an emergency shutdown.

[tuxedoxt]

I experimented with my workaround turned off since a few days:

@tuxedoxt I just got another CPU emergency shutdown because tccd at 0 nice reacted too late to order a fan speed up.
I was doing encoding work using ffmpeg from some time of complete standstill in temperatures and fans (CPU at ~50ºC and GPU at ~45ºC).
Then I try to run ffmpeg, leading to a very high CPU usage at 0 Nice.
At ~3 seconds of ordering the encode, I could notice changing windows was starting not to respond and I could notice the fans were not speeding up.
At ~4 seconds of ordering the encode, I ordered a full blast on the fans Fn+1.
At ~4.1 seconds of ordering the encode, emergency shutdown happened; the fans were still ramping up

At no point in those 4 seconds I heard the fans blowing beyond low (almost silent) rpm.

I recommend that tccd should run at a RT priority class and should not do all the "smooth" ramp-up in fan speed when the temperatures are above (in my PC's CPU case) 90ºC. In my case, I'm sure it reached the 105ºC and got an emergency shutdown.

Thank you for the information. I will run some tests with devices similar to yours. So far only observed fast temp increase with sufficient throttling. Is yours with or without discrete GPU (nvidia)?

Does openssl speed -multi 8 also produce enough load to cause the issue?

I tend to agree, there could also be room for a "fallback" fast increase mode in the case of really high temperatures.

[brunoais]

Is yours with or without discrete GPU (nvidia)?

With discrete GPU. Two fans.

Does openssl speed -multi 8 also produce enough load to cause the issue?

It does. It fails easily and seems easy to reproduce. I only did it twice because I don't want to stress my PC's CPU

[brunoais]

With the current changes where the user can change the fan settings, I confirm that I'm getting better results by increasing the base fan speed when needed.
However, if I forget to do so, the problem still persists.
To solve that, I made 2 profiles. One with boost and fans rotating faster and one without boost where fans rotate slower.
This is a workaround, though.
A way to handle this, for starters, would be tcc to have much higher priority. Maybe one of the higher real time priorities.
Then, it would be for tcc to give priority to ramp up for higher temperatures and not let at 80ºC, the fans rotating at 30% and, at 90%, fans at 40% because it's still ramping up to reach the 90%. If the CPU is at 90ºC, just put them immediately to the speed setting for that temperature.

[brunoais]

Issue has disappeared in the meantime. Closing this as fixed