Fan RPM doesn't follow linear steps fan curve

[dduits]

Describe the bug
The actual RPM of a fan that is controlled by fan2go doesn't match the linear fan curve defined in /etc/fan2go/fan2go.yaml, the actual PWM value always seems to be a certain amount above the specified PWM value. For example, when specifying a linear fan curve with the following steps 55 -> 60, 60 -> 90, 90 -> 255 (°C -> PWM) and having a sensor input temperature of 42.0 °C, fan2go will report Setting Fan PWM of 'front_intake' to 81 ... instead of a PWM value around 60. This results in the actual fan RPM being higher and the fan making more noise than expected.

To Reproduce
Steps to reproduce the behavior:

1. Define a linear fan curve with steps for a particular fan in /etc/fan2go/fan2go.yaml

...
curves:
  - id: front_intake_curve
    linear:
      sensor: cpu_tctl
      steps:
        - 55: 60
        - 80: 90
        - 90: 255

2. Observe the fan RPM and sensor temperature specified for the fan curve. In my case Tctl (CPU temperature of my AMD Ryzen 9 5950X) with the following command: watch -t -n0.5 'sensors | grep "fan*\|Tctl\|Tccd"'
3. Run fan2go with the verbose flag (fan2go -v) as root and observe the PWM DEBUG logs (e.g. Setting Fan PWM of 'front_intake' to n)
4. Observe the fan2go setting the PWM ~20 points higher than the PWM specified value in the temperature/PWM value in fan2go.yaml

Expected behavior
I expect fan2go to match the specified linear fan curve defined in fan2go.yaml. I.e. when Tctl reports a temperature lower than 55 °C fan2go send a PWM signal of 60 to the defined fan.

Here's a graph that illustrates what I'm trying to achieve with with the fan curve described above:

Screenshots

Screencast_20240715_190146.webm

The DEBUG logs show the PWM value sticking at 82 PWM even though the Tctl is below the first step (55 °C -> 60 PWM) in the linear fan curve.

Desktop (please complete the following information):

• Distro: Arch Linux
• uname -a: Linux jade 6.9.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 12 Jul 2024 00:06:53 +0000 x86_64 GNU/Linux
• sensors -v: sensors version 3.6.0+git with libsensors version 3.6.0+git
• fan2go version: 0.8.1

Additional context

Minimal fan2go.yaml used to reproduce the bug

fans:
  - id: front_intake
    hwmon:
      platform: nct6798-isa-0290
      rpmChannel: 3
    neverStop: true
    minPwm: 30
    startPwm: 30
    curve: front_intake_curve

sensors:
  - id: cpu_tctl
    hwmon:
      platform: k10temp-pci-00c3
      index: 1

curves:
  - id: front_intake_curve
    linear:
      sensor: cpu_tctl
      steps:
        - 55: 60
        - 80: 90
        - 90: 255

Hardware

Fan: Noctua NF-A14 PWM chromax.Black.swap
Motherboard: ASUS ROG STRIX X570-E GAMING WIFI II

[dduits]

As far as I can tell the PWM offset might be result of the minPwm, both the manually specified value in the fan2go.yaml and the auto detected value seem to cause the PWM value to stick around 81.

Setting minPwm to 0 in the fan2go.yaml strangely enough causes the PWM value to drop below the specified fan curve value of 60:

[markusressel]

Hi @dduits , sorry for the late response, life is life sometimes.

There was an issue with how the PWM mapping was applied, as well as the PID controller interacting with the sensor readings.
I have made a lot of adaptations and improvements, including a boatload of tests in #267 which will hopefully be merged relatively soon.

Since you seem to have already invested a lot of time into analysis I would be more than happy if you would be able to check out the branch and make build it to test it out on your system and see how it behaves compared to the currently released version.

Let me know if you need any assistance.

[markusressel]

@dduits the mentioned branch has been merged a while ago, feel free to use the latest version to gather some data :)

[dduits]

Hi @markusressel

I've actually been testing v0.9.0 shortly after the tag was made and became
available through the AUR.

As far as I can tell fan2go now correctly follows the configured fan curve.
Here are some screenshots of some simple testing I did yesterday.

If you have any specific configurations/use cases you'd like me to test, just
let me know and I can post some results here. Otherwise, at least from my
perspective, I consider this bug fixed.

Thanks for putting in the hard work and please excuse my delayed reply.

[markusressel]

@dduits That sounds great!

I don't have any specific scenarios, if yours is working as expected now I think we can close this issue for now. If anything else comes up, feel free to open a new issue.

Thx for your work as well ❤️