You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, (and sorry for the following large text...)
I use MacFanControl since recently on my 2013 MacbookAir, and it's GREAT help, a big thanks for the app . I have set fan speed accordingly to cpu-core-temp (increase fan spee from 60°C, set max speed from 90°c) and it woks nice, as soon as the cpu-temp reach the values the fan speed increase too, cooling the cpu really efficiently . (Before that MacOS was letting the cpu reach really high temperatures like 100°C before to really start the fan :-/ ) .
BUT, however ... I find the MacFanControl algorythm is quite "agressive" in its way of reacting to temperature changes .
I mean : cpu-core-temp can increase in a fraction a second for a lot of degrees, BUT the opposite is true too if the temp-increase comes from a peak of temporary resource demand . (A peak of cpu-power-consumption doesn't have time to heat enough to set thermal inertia to the processeor, as it's just a peak) .
Example : the computer is idle and then you start a "big" app (like firefox) : the result at cpu level is a (big) peak of consumption, followed quite instantly with a big core-temperature elevation (from 50°c to 80°c in a quarter of second) . BUT, both are temporary : a few second later Firefox has started so there is no more high power consumption, the cpu will be back to idle level and its temperature will naturaly quiclky follow the curve (as this was just a peak : really low thermal inertia) . The total elapsed time from : idle to power.peak to idle is like 2 or 3 seconds ... BUT, with the current behavior of M.F.C, I observed there is no delay (or a really really small/short one...) when the app sees this kind of temprature increase .
The result is : M.F.C sees that the cpu-temp exceeds the threshold value (60°c in my case), so instantly he put the fan at high (noisy!!) rpm, then one (or two) second later he will "stop it" (because the temperature as already naturaly decreased under the threshold value, as the temporary power/temp-peak has faded...) . M.F.C respected the values, and did what expected, no error ... BUT, however : in daily use this behaviour is quite annoying (not a sooooo big deal but not comfortable...), cause finaly as soon as you start a program : you will get a noisy/high-speed fan for some seconds, despite it's not really necessary ...
Question : Is there a way to adjust some kind of "reacting delay" for the user ? Like : wait two or "X" second before to start the fan in case of sudden cpu-temp-core increase (and if the temperature persists to stay high after those few instants then the fan will start and keep the rpms as long as the temperature has not lowered...) .
I checked the M.F.C documentation but didn't see anything relative to this "feature" ... I expected something like that in the pro version I was planning to buy . Is it a "missing" feature ?
Thanks for help :-) .
[Edit - same day, few hours later]
After thinking at that issue .
I ran some tests with 3 youtube video at 1920x1080 def, simultaneously played and displayed on the screen, in order to stress that (poor old 2013 macbookair) 1.3GHz processor while keeping an eye on M.F.C. temp-probes-results, to see what's what for each . And letting the fan-management in the hand of MacOS (which is slow to act on cooling...) .
I ended up with a good conclusion :
instead of using cpu-temp-probe I can choose to read the cpu-proximity-sensor as driver for fan management (with custom values of course) . Cause the cpu-proximity has more "inertia" in changes (obviously he is not inside the processor so...) than the cpu-sensor . So in case of cpu-peak he won't sense it fast, and as by definition a peak is short : then the cpu will have time to cool naturaly after (even with fan under 2000rpm which is my hear threshold), while the proximity-sensor would not even have noticed the peak . Job done :-) .
My custom value to keep my mba silent in "daily low end tasks" and even in case of cpu-peak are now (for the cpu-proximity-sensor!!) :
52°c for "temperature that the fan speed will start to increase from"
65°c for "maximum temperature" .
Those settings works perfectly :-)
Now in case of temporary cpu-peak (like less than a minute) from an idle state : M.F.C. don't run the fan above 2000rpm as the cpu-proximity sensor don't even "see" the peak .
But in case of continuous big cpu sollicitation (more than a minute) the cpu-proximity sensor will notice it and then start to rise the fan's rpm slowly but surely, untill they reach the max, keeping the processor "cooled" (if 95°c may be conseidered as "cool") . In that last scenario, compared to use the cpu-sensor in terms of behaviour, the fan is started a bit later and is shuted-down a bit later too (proximity-cpu-sensor is "slower on the uptake" but as a bit more inertia), finaly there is no change on the total overall time . Tadammmm :-) .
If it may help others :-) .
[/[Edit - same day, few hours later]
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello, (and sorry for the following large text...)
I use MacFanControl since recently on my 2013 MacbookAir, and it's GREAT help, a big thanks for the app . I have set fan speed accordingly to cpu-core-temp (increase fan spee from 60°C, set max speed from 90°c) and it woks nice, as soon as the cpu-temp reach the values the fan speed increase too, cooling the cpu really efficiently . (Before that MacOS was letting the cpu reach really high temperatures like 100°C before to really start the fan :-/ ) .
BUT, however ... I find the MacFanControl algorythm is quite "agressive" in its way of reacting to temperature changes .
I mean : cpu-core-temp can increase in a fraction a second for a lot of degrees, BUT the opposite is true too if the temp-increase comes from a peak of temporary resource demand . (A peak of cpu-power-consumption doesn't have time to heat enough to set thermal inertia to the processeor, as it's just a peak) .
Example : the computer is idle and then you start a "big" app (like firefox) : the result at cpu level is a (big) peak of consumption, followed quite instantly with a big core-temperature elevation (from 50°c to 80°c in a quarter of second) . BUT, both are temporary : a few second later Firefox has started so there is no more high power consumption, the cpu will be back to idle level and its temperature will naturaly quiclky follow the curve (as this was just a peak : really low thermal inertia) . The total elapsed time from : idle to power.peak to idle is like 2 or 3 seconds ... BUT, with the current behavior of M.F.C, I observed there is no delay (or a really really small/short one...) when the app sees this kind of temprature increase .
The result is : M.F.C sees that the cpu-temp exceeds the threshold value (60°c in my case), so instantly he put the fan at high (noisy!!) rpm, then one (or two) second later he will "stop it" (because the temperature as already naturaly decreased under the threshold value, as the temporary power/temp-peak has faded...) . M.F.C respected the values, and did what expected, no error ... BUT, however : in daily use this behaviour is quite annoying (not a sooooo big deal but not comfortable...), cause finaly as soon as you start a program : you will get a noisy/high-speed fan for some seconds, despite it's not really necessary ...
Question : Is there a way to adjust some kind of "reacting delay" for the user ? Like : wait two or "X" second before to start the fan in case of sudden cpu-temp-core increase (and if the temperature persists to stay high after those few instants then the fan will start and keep the rpms as long as the temperature has not lowered...) .
I checked the M.F.C documentation but didn't see anything relative to this "feature" ... I expected something like that in the pro version I was planning to buy . Is it a "missing" feature ?
Thanks for help :-) .
[Edit - same day, few hours later]
After thinking at that issue .
I ran some tests with 3 youtube video at 1920x1080 def, simultaneously played and displayed on the screen, in order to stress that (poor old 2013 macbookair) 1.3GHz processor while keeping an eye on M.F.C. temp-probes-results, to see what's what for each . And letting the fan-management in the hand of MacOS (which is slow to act on cooling...) .
I ended up with a good conclusion :
instead of using cpu-temp-probe I can choose to read the cpu-proximity-sensor as driver for fan management (with custom values of course) . Cause the cpu-proximity has more "inertia" in changes (obviously he is not inside the processor so...) than the cpu-sensor . So in case of cpu-peak he won't sense it fast, and as by definition a peak is short : then the cpu will have time to cool naturaly after (even with fan under 2000rpm which is my hear threshold), while the proximity-sensor would not even have noticed the peak . Job done :-) .
My custom value to keep my mba silent in "daily low end tasks" and even in case of cpu-peak are now (for the cpu-proximity-sensor!!) :
Those settings works perfectly :-)
Now in case of temporary cpu-peak (like less than a minute) from an idle state : M.F.C. don't run the fan above 2000rpm as the cpu-proximity sensor don't even "see" the peak .
But in case of continuous big cpu sollicitation (more than a minute) the cpu-proximity sensor will notice it and then start to rise the fan's rpm slowly but surely, untill they reach the max, keeping the processor "cooled" (if 95°c may be conseidered as "cool") . In that last scenario, compared to use the cpu-sensor in terms of behaviour, the fan is started a bit later and is shuted-down a bit later too (proximity-cpu-sensor is "slower on the uptake" but as a bit more inertia), finaly there is no change on the total overall time . Tadammmm :-) .
If it may help others :-) .
[/[Edit - same day, few hours later]
Beta Was this translation helpful? Give feedback.
All reactions