Here’s another patch for some third party software, this time for keeping your intel mac CPU cool.
I’ve been using Lobotomo’s Fan Control preference pane and daemon to control my 2.16 GHz Core 2 Duo Macbook Pro’s fan speeds since I installed OS X.
It’s useful because it means you can idle with quieter fans in a cool environment, but still have them rev up to max before you burn your fingers. However, one thing that’s annoyed me for a while is that you only really control the floor and ceiling thresholds of a linear response curve.
In my experience (engineers or physicists can correct me), at a constant CPU load, there are multiple equilibrium temperature/fan-speed combinations, but they’re not collinear. In the original Fan Control, the response curve is linear. Taking a hint from gamma correction, I have patched Fan Control 1.2 to use an exponential curve. Where T is the temperature, the target fan speed F is governed by the equation:
I also reduced the minimum upper threshold temperature to 60˚C.
You can browse the source in git or download the binary installer. I’ve only tested on the MacBook Pro (running Leopard). Feedback is welcome as comments here on the blog.
Of course, there may be more effective measures to combat a hot macbook pro.
Good idea with the exponential response curve.
I do have an issue though (that I think is present at the traditional linear version too). The actual fan speed doesn’t seem to stick to the response curve set up. Actual fan speed can be a lot more than response curve gives for a given temperature, even after minutes to have a chance to stabilize. Now running at 5750 rpm at 75 degrees celcius even though response curve is set to around 4000 rpm at that temperature. Any ideas / fixes?
Testing with 100% constant load using CPUTest on a MacBook 4,1.
Any chance to make a 64-bit version / compilation? To not have Snow Leopard reload the System Preferences when using the pref panel.
The “extended” version available at http://www.derman.com/MacBook-Pro-Fan-Control seems to also have issues hitting the desired rpm according to the set response curve. Perhaps Fan Control simply cannot have full control, but can only set minimum rpm?
This post talks about “automatic” vs “forced” mode. Don’t know if that gives any hints…
What’s nice about this “extended” version is that it shows, in both numbers and plots, desired vs current fan speed – clearly showing the issue I would love to have solved.
I’ve recompiled as an x86 + x86_64 universal binary against the 10.5 SDK, and made the Fan Control +exponent installer available at the original URL. The 10.4 API version has been moved for historical reference.
The code in MFDaemon.m moves the hardware target fan speed toward the curve’s target at a decelerating rate, until it gets within 20rpm of the target. The disparity you’re experiencing is more likely due to Apple’s limits when the fan is in auto mode.
I’ve also built the smc tool if you want to play with the settings from the command line (you can change the mode to forced, and observe the target vs actual).
I tried to install the x86_64, but pref panel still reopens using the 32-bit version – don’t know why. It seems the x86_64 binary should be included:
file Fan\ Control
Fan Control: Mach-O universal binary with 4 architectures
Fan Control (for architecture i386): Mach-O bundle i386
Fan Control (for architecture x86_64): Mach-O 64-bit bundle x86_64
Fan Control (for architecture ppc7400): Mach-O bundle ppc
Fan Control (for architecture ppc64): Mach-O 64-bit bundle ppc64
Not sure I understand the auto vs forced mode. Is it possible to set the pref pane / daemon to more strictly follow the set response curve? It seems to never hit as low a target as I want when higher temperatures are seen. Is it an Apple safety mode that cannot be overwritten?
Essentially “auto” mode allows the hardware to override the targets the Fan Control daemon sets. You can set it to forced mode with the smc tool I linked in my last comment:
sudo ./smc -k 'FS! ' -w 0003After which, if you run
./smc -fit should show both fans in forced mode.I don’t provide a way to do this via the GUI since I figure Apple has auto mode to stop people melting their hardware.
Thanks for the help on smc. I’ll try it out.
Any idea why I cannot make the 64-bit compilation of the fan control work out as expected (see earlier post)?
Tried to set forced mode now via smc, but had not expected the rpm to stay at a constant rpm because of this (rate at point of issuing command).
I thought Fan Control would still change the target speed dynamically according to temperature change, and the difference would be that the fan actual strictly followed the response curve in Fan Control without being restricted by auto mode’s safe limits. Is this not possible?
When running in auto mode with Fan Control installed, and Fan Control’s response curve is set to give somehing like 4000 rpm at given temperature, I’m surprised to see smc -f report this:
Fan #0:
Actual speed : 6208
Minimum speed: 4577
Maximum speed: 6200
Safe speed : 0
Target speed : 6200
Mode : auto
I would have guessed, or hoped, that Fan Control would at least be able to set target speed to the minimum speed reported above, and not stay at maximum speed, even after a long time to stabilize.
Maybe the temperature is getting misread? Try this:
smc -r -k TC0DYou should then take the output bytes (little endian) and divide by 256 to get a temperature in degrees C. e.g. if the output is:
TC0D [sp78] (bytes 3e d0)0x3ed0 = 16080. 16080 / 256 = 62.8 C.
If you check with other tools, does that look right?
I tried, and the smc reading matches what iStat menu and Fan Control pref pane is showing. Only CoolBookController is reporting a lower number, but is only tool I have seen disagree, and the developer is notified about the issue.
So there must be another reason why target speed is not set by Fan Control to closest match between min and max reported by smc.
Thanks for this version, it is really nice. The daemon runs in 64bit mode, however the prefpane only opens in 32 bit mode (lion).
Cheers & thanks again!