-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enhancement: option to smooth temperature data #176
Comments
Can confirm the spikes on P1 Gen 4 (i7-11800H) as well |
I came here to ask for sth. similar and found this :) So I second such an option, seeing such spikes on my Lenovo T580 with i7-8550U due to the TurboBoost behaviour. |
It's certainly an interesting proposal, but the upcoming 2.0 release is pretty full already with some long-standing bugfixes and another major documentation overhaul for multi-fan support. So I think I'll take a closer look at this for 2.1... |
Just thought a little more about @jdchristensen's statement that the
With
effectively canceling out the spike. With
Which would keep some of the spike. In fact, I'd consider the behavior with So I guess my question is: Why not use something like edit: not entirely sure ;-) |
Also note that in modern laptops the fan's heat exchanger never sits directly on the CPU's heatsink, but is connected to it with a heatpipe that further increases heat capacity and delays the effectiveness of active cooling. So unless I'm overlooking something fundamental, I'm pretty certain there's really no point in reacting at all if temperatures drop down again before we even started reacting. |
@vmatare I agree that the goal is to not turn the fan on at all when the spike is brief. But I don't understand the example bias calculations you did, and how they result from the formula Also, the spikes I'm talking about are much more dramatic. At one second intervals, I'll see temps like 39, 41, 39, 95, 40, 39. It's that 95 that I want to ignore, and so the amount of bias needed would be huge. |
Yeah, when calculating the examples I noticed that the formula in the manpage doesn't describe the whole truth. The actual behavior is a little more complex. However in the simple example you gave, it works just as the formula says, e.g. for
So the only interesting part is the jump from 39 to 95, i.e.
HOWEVER:
The behavior is this weird because it was designed to also allow for exaggeration of temperature increases by giving a positive bias. Nowadays this seems to be getting rarer, but older CPUs could have a very slow load-to-temperature response because the temperature sensors were much further away from the DIE. So most importantly: have you tried running thinkfan with e.g. |
btw, I also noticed an error in the example I gave above. The actual behavior should be more like this: With
With
The difference here being that slow decrease of the bias offset doesn't kick in, but instead the normal biasing formula is applied on each increase because |
@vmatare Thanks for giving more explanation. I think that this comment you made shows that there is still a fundamental problem with how the bias works:
Because that will certainly happen. A second issue is that I don't understand the other examples you gave. Also, with In summary, however bias works, it seems very hard to explain and doesn't really do what one wants. A smoothing filter, which is trivial to implement and explain, seems better suited to handling spikes. In a sense, this models how the heatsink itself will be smoothing out the die temperatures. |
If this helps in any way, I can collect some data, for instance append CPU temp and fan speed every second to a txt file. Maybe that'll give some insight into the spikes. If you want me to run some specific command, let me know, will do. |
On my X1 Extreme Gen 4, the CPU package temp and core temps often briefly spike up, but then immediately drop down. This causes thinkfan to turn the fans on, but by the time they ramp up, the spike is already gone. I know about the bias option, but the spikes are too large to be managed by it without compromising desired increases. I propose adding an option
-w weight
which smooths things out by forming a weighted average of the new reading with the old accumulated value. Hereweight
is a floating point number between 0 and 1, and we would calculate:When
weight=1.0
, we just use the newsensorreading, as before, but whenweight=0.7
, say, we would smooth it out by averaging against the previous accumulated value (not the previous raw reading).The text was updated successfully, but these errors were encountered: