search

markusressel / fan2go

A simple daemon providing dynamic fan speed control based on temperature sensors.
GNU Affero General Public License v3.0
226 stars 21 forks source link

My fan curve is not detected properly (Min, Start, Max = 0) #316

Open WildPenquin opened 4 days ago

WildPenquin commented 4 days ago

Describe the bug

Fan curve is not detected properly. Fan2go does draw a curve, but at zero the fan is running. Hence it decides stop=min=max=0.

To Reproduce Steps to reproduce the behavior:

run: `fan2go fan init -i [afanname]

Expected behavior

Fan curve should be detected correctly.

In case the fan is slow to stop, there should be some sanity check. The whole process should not require a longer -e parameter just because a slow to stop fan. There should be a sanity check (wait longer at 0).

I've yet to test with a larger -e value to see if the problem goes away. I believe this is caused by fan2go setting pwm to 255, then to 0, but the fan does not stop in 2 seconds.

Screenshots

❯ sudo fan2go fan init -i "Intake_pull"
 INFO  Using configuration file at: /etc/fan2go/fan2go.yaml
 INFO  Using persistence at: /etc/fan2go/fan2go.db
 INFO  Deleting existing data for fan 'Intake_pull'...
 INFO  Computing pwm map...
 INFO  Measuring RPM curve...
 SUCCESS  Done!
 INFO  Using configuration file at: /etc/fan2go/fan2go.yaml

Intake_pull

  Min PWM    0
  Start PWM  0
  Max PWM    0

 1729 ┼╮                                                                                             ╭────
 1614 ┤│                                                                                     ╭───────╯
 1498 ┤│                                                                             ╭───────╯
 1383 ┤│                                                                     ╭───────╯
 1268 ┤│                                                              ╭──────╯
 1153 ┤│                                                       ╭──────╯
 1037 ┤│                                                 ╭─────╯
  922 ┤│                                          ╭──────╯
  807 ┤╰╮                                   ╭─────╯
  692 ┤ │                             ╭─────╯
  576 ┤ │                        ╭────╯
  461 ┤ │                   ╭────╯
  346 ┤ │       ╭╮    ╭─────╯
  231 ┤ │       │╰────╯
  115 ┤ │       │
    0 ┤ ╰───────╯
                                                    RPM / PWM

Other info On my setup, things may be exacerbated by the fact there are fans on a rad in push-pull configuration. While I've tried multiple times to initialize all fans at the same time with fan2go, case may be their momentum is such that it maintains some airflow and the fans are more slow to stop than usually.

markusressel commented 4 days ago

Hi @WildPenquin, thx for reporting!

Yes, the automatic curve detection algorithm is not exactly great at the moment. The easy fix for this is to set the minPwm, startPwm and maxPwm yourself, since the curve is currently not (yet) used to control the fan speed.

Of course that't not a solution for the automatic detection, which should also work for your case, so I will leave this issue open for now.

WildPenquin commented 4 days ago

I've set the minPwm, startPwm and maxPwm to work around the issue.

However I did some more testing. I'm using a Corsair Commander Pro. It's either the fans or the Commander Pro acting up. I believe it's a combination of two things:

I.e., I can reproduce this weird behavior of the fans manually (without fan2go) by these steps:

I also get a really, really slow startup every time I start fan2go. I believe I'm experiencing issue #132 although it seems like it has been fixed. The persistent PWM mapping is not working, as I can see by enabling verbose on fan2go (but perhaps I should open a separate issue or comment in #132).

markusressel commented 4 days ago

Yeah there were multiple issues already regarding the Corsair Commander Pro, see: https://github.com/markusressel/fan2go/issues?q=is%3Aissue+Corsair+Commander+Pro+is%3Aclosed I am afraid there is only so much we can do about the weird behavior of this device.

There was an issue fixed very recently regarding the pwmMap, see #311 .

Also, there have been lots of improvements in #267 but I am still trying to find the time to test it thoroughly. If you are comfortable with it, maybe checkout the branch in #267 and run 

cd fan2go
make build
./bin/fan2go --your --config --params

to test it out. Would be awesome to have some third party testing info on it :)

GitHub
Issues · markusressel/fan2go
A simple daemon providing dynamic fan speed control based on temperature sensors. - Issues · markusressel/fan2go
WildPenquin commented 4 days ago

The Corsair Commander Pro is a bit special hardware, indeed.

I don't know it's internals nor how the Kernel driver works, but it doesn't have any pwmXenable as "real" sensor chips. Instead it has the fanX[input/label/target], and setting via the _target actually gives more fine-grained control and works fine. I've been using this in a custom program for controlling my fan speeds (and AFAIK liquidctl also uses these nodes?) and it works fine. However fan2go core logic and configuration relying on PWM values (AFAICT, I've just now found this software) it would be quite difficult to write an implementation to use the fan?_target nodes instead....

But you probably know all of this already.

I'll see the mentioned branch later and report back :-)

markusressel commented 4 days ago

But you probably know all of this already.

Not really, since I don't use this hardware :smile:

However fan2go core logic and configuration relying on PWM values (AFAICT, I've just now found this software) it would be quite difficult to write an implementation to use the fan?_target nodes instead....

Well, fan2go was initially created with a 0..255 range in mind, yes. However, it is already possible to map this internal range to something different (like 0..100). fan2go also already supports different types of fans and sensors, like hwmon based ones and file based ones. So I don't think it would be far fetched or very difficult to support something slightly different as well, especially with the improvements made in the mentioned branch.

However, the biggest issues is the one I wrote at the top: I don't own this hardware. It doesn't make much sense for me to add support for something I don't own or use and cannot test on a regular basis - even though I would like to.