Is macfanctld still maitained ?

[bitsandnumbers]

If not, is there an alternative for macbook pro's ? Thanks

[pyrovski]

You could try mbpfan. The macfanctld maintainer doesn't use it anymore.

[nathanael-naeri]

It still works though (pretty well on my computer, as far as I'm concerned). The last official version, 0.6, was packaged for Debian by Thibaut Paumard, and has since made its way into the official Ubuntu repository. There are also two different, unofficial versions 0.7 in Ubuntu PPAs, implementing two different sets of changes: one packaged by Jason Heeris, that implements the changes proposed by the previous commenter, and one packaged by Eugene San, that implements the changes he proposed.

Whatever the version though, I think it's worthwhile to adjust the values in the configuration file to match one's own hardware.

I've yet to try mbpfan but I'm sure it's good too, because its developer mentions Archlinux users are the main user base, and I trust these folks.

[ssbarnea]

I have some concerns that macfanctl does hog the cpu on recent versions of Ubuntu.

[nathanael-naeri]

I Sorin, this is not supposed to be the case. If you can reproduce this problem please open a new issue and provide more information. I'll try to help.

[ssbarnea]

@nathanael-naeri thanks you! I already installed mbpfan about one week ago and now I am not able to see it as a process that takes any measurable CPU time.

[nathanael-naeri]

Alright, all good then. Yeah both programs should only take a negligible fraction of CPU time. Cheers.

[pobetiger]

Hi there,

I'm running macfanctld on my i7-quad mac-mini from late 2012 on Arch/Manjaro. I expect to be using this tool for a while.

Despite what some of the guys on launchpad might say about adding new features, I felt that if I'm going to be using this tool, I want it to be running slightly more robust code. So I did some minor rewrite and merged all the recent forks that I can find on github.

Mainly I wanted to fix hardcoded config file line limits and excluded sensor count. Secondly, to clean up the file reads per each requested entry issue. My build uses an in-memory key-value pair table to store all the config entries and only hits the harddrive once when the conf file is read/refreshed.

It's working on my box relatively well enough (the conf does require tweaking out of the box and is a bit noisier comparing to stock osx settings). I'm running systemd and I do not have debian/ubuntu to test. So beware.

I intend on adding a new log mode that will dump the log to /tmp instead of /var/log to reduce disk access (for ssd users, i know, no persistence, it's a trade-off option). And I plan on working on some sysfs or maybe /proc hooks to allow status query that might pave way for a gui or at least from conky or something. No timeline yet.

I'd love to have someone look over and give some feedback if any of you are still interested in this tool.

pobetiger

[almson]

@pobetiger Do you have an AUR? My biggest gripe with the current macfantld is that it's completely unclear how it constructs the fan curve and why it's not smooth at ramping fans up and down.

[pobetiger]

@almson, sorry it took a long time to reply, I have been ignoring my github emails...I may have signed up for too many notifications. :D

And no, I have not published anything to AUR. I actually have been doing more Void Linux and *BSDs lately. Systemd is getting a little annoying on some of my other machines and I've been exploring getting rid of it altogether, hence I didn't want to spend too much effort with AUR). But given Debian-based vs Arch-based choice, I would go with Arch and dockerize when I need Debian/Ubuntu versions of stuff.

Make sure you have my latest build though, as I've fixed some issues with the exclude list, which can give you problems with the fan speed math (see math below). The original code has a line character limit in the config file on how many sensors you can exclude and on my mac mini, more than half of the sensors need to be excluded to make the numbers reasonable.

Here's what I get from reading the control.c code:

fan_speed (all fans speed) is controlled based on 4 factors (in order of priority):

1. TG0P (gpu0 proximity) if req speed > TC0P speed
2. TC0P (cpu0 proximity) if req speed > Temp_max speed
3. Temp_Max if req speed > Temp_avg speed
4. Temp_Avg if Temp_Avg speed > idle (min) speed
5. Idle min speed (You will see these in control.c calc_fan() and they appear in reverse order)

Temp_Avg is the average of all the sensors not in the excluded list. Temp_Max is the max of the sensors used to calculate Temp_Avg. Max fan speed is hardcoded at 6300. May need to be adjusted for mac's with higher specs???

There's a limit to 100 sensors. (Probably something to fix later, I don't like hardcoded limits...)

In 3 of the cases, the fan_speed is calculated using this formula:

speed = (max speed - min speed) * ( (curr temp - min temp) / (max temp - min temp) )

In the case of the Temp_Max a minimum speed threshold is specified, so the equation turns out to be:

speed = temp_max_min_speed + (max speed - min speed) * ( (curr temp - min temp) / (max temp - min temp) ) I've found sensors might read -127 or some other large or otherwise invalid numbers, and those can skew the Temp_Avg quite a bit. So if your TC0P and TG0P is not particularly strict, you can end up with the Temp_Avg being the main determining factor in driving the speed of the fan.

The priority should also be looked at, it should be based on the actual location of the sensors on the motherboard relative to important things instead of the arbitrary order.

The choppy feel of the fan speed adjustment is due to the fact that the adjustments are made in a simple wait loop:

read_sensor() -> calc_speed() -> set_fan() -> process sleep -> repeat.

Two factors will make the fan adjustments choppy:

1. The stepping of the speed is not integrated over time so the fans can seem choppy jumping from one speed to the next based on the update_time config parameter. A proper PID algorithm on the fan speed (or even just an integrator factor) can probably smooth out the process. mbpfan uses step up and step down (https://github.com/dgraziotin/mbpfan/blob/master/src/mbpfan.c), which is another way to do it, around line 532.

2. The way the there are multiple modes of speed adjusts (from gpu0 vs cpu0 vs avg vs max) also doesn't help. It could go from idling to suddenly going max (coupled with the aboove). And actually knowing what those sensors all mean or exclude them all can help with that. On mbpfan, they only look at the processor temp to avoid the modal switches. One can argue that the gpu is probably not going to overheat as bad as the cpu, or that the fan might be too remote from the gpus to actually help, hence making it simpler, etc.

Hope that explains part of the fan curve and the control process. I think the algorithm in macfanctld is simply enough to understand and change, hence I picked this. Looking at mbpfan, I am envious of all the unit test cases they have...

[Swampfox-cyber]

This works on Linux Mint dual booted on a Mac mini (Late 2012 Mac mini). Other programs in the Linux Mint software store would make the fan blow at 110% (At least that's what it sounded like). With macfanctld, it seems to speed up as it should under a heavier load and slow when not busy. Without it, this thing was super hot. FYI, all minis seem to run hot anyway no matter what you do. They just seem to be able to take the heat. macfanctld seems to make it run slightly cooler than OEM, but I can live with that.

[JoergOstertag]

I have a late 2011 iMac here with a replaced HDD. So when i started a fresh Ubuntu install both (mbpfan and macfanctld) were installed. But each of them had a little bit missing.

• macfanctl is not handling the 3rd Fan (CPU)
• mbpfanis not watching out for high temperature on the GPU or others.

Looking at the last commit I decided to adapt mbpfan. So I started to add a little hack to mbpfan and add reading of the other temperature values. It's only a hack, but with my first tests my iMac is not instantly overheating and not blowing like mad. I someone else could have a look at this first Try ... https://github.com/JoergOstertag/mbpfan

[gaul]

Please open a pull request against mbpfan with GPU temperature checking.

[ablakely]

I'm working on a fork that's compatible with my 2006 Mac pro, which has 4 fans instead of 2, I also have a 2015 macbook pro I can test it on. I don't have any other macs to test with besides some PPC machines. I also intend to make fans quieter at least on my mac pro.

[ablakely]

I have completed my fork to the point I feel like it's a proper replacement for this daemon. It uses a new config file format as well as profiles for individual machines so it's able to be tuned to run the best on multi fan systems. It currently supports up to 18 fans (for xserve, I plan to test on one day... lol)

Feel free to check it out, https://github.com/ablakely/macfand/

[ssbarnea]

@MikaelStrom Are you still with us? I am asking because it would be awesome if macfanctld would get a new life by being transferred under a github organization where those interested can continue maintaining it instead of forcing them to fork it.

[gaul]

Again, please look at mbpfan which has more active development and its own org...

[ablakely]

mbpfan as well as macfanctld are targeted for macbooks, mbpfan will work on other machines with up to 10 fans but doesn't seem to be as responsive as I'd like, from my testing. That's why I made my project, which also allows more tuning options than either.

[pobetiger]

@ablakely - I used to maintain my own fork of macfanctld. At one point I modified the code to allow more flexible allocations, but I realized I don't want to rewrite my own unorderd_map. So I have since then redeveloped my own version of it in modern C++ with a json config file. https://github.com/pobetiger/macfanpp - I tried to keep the same design concept as macfanctld with the same algorithm.

And I have been using it daily on my macmini and my mbp14,2 for work as well doing kernel and operating system development. And of course some gaming as well.

Some of the things I've done:

• I've added/compiled a consolidated a list of names of the sensor device names from various lists (so it's not just cryptic naming)
• Switched to json format - unlimited number of sensors and fans, and unlimited exclude list, etc.
• I've turned on Werror, and Weverything to build using Clang++ on C++20 to make sure the code is warning free.
• I am also working on a DBus integration so that you can subscribe to signals and have your own GUI in other languages/UI designs. (staged/unpushed)
• I have also done some refactoring to make the components more isolated (staged/unpushed)
• I do plan on adding unit tests to get better coverage.
• There is no install, I have to do some documetnation on how that's supposed to work.

Feel free to check it out.

[gaul]

@ablakely mbpfan works on desktop models as well: https://github.com/linux-on-mac/mbpfan/wiki/Tested-Mac-Models#tested-imacmac-mini-models= . mbpfan has packages for major Linux distributions which is a major advantage to most users.

It would be nice to unify efforts with one project instead of diluting over multiple ones. Is there something blocking working together? I am the current mbpfan maintainer but but longer-term I plan to buy more Linux-compatible hardware since post-2015 MacBooks and M1/Asahi seem challenging.

[ablakely]

@pobetiger it seems we have implemented some of the same functionality as far as individual fan control.

@gaul I'm not opposed to such, but implementing the changes I have made would take more collaboration than just a pull request, I think. For example I have made changes to be able to offer a stock known working configuration that performs well through the concept of a "profile" which can be overridden through the users config file.