Very slow startup

[j4ncp]

Describe the bug
Not sure this is a bug or not, but the behavior I am seeing is the following: at boot, the fans are at 100%, then as fan2go is started, they slowly decrease PWM down to 0%, and only then they finally go to the PWM that corresponds to the current control scheme based on temperature. This whole process takes about a minute or two. Not sure if this is intended or not; if it is intended I guess I would like to know the reasoning, if not it should probably be fixed. Note: this does not refer to the very first calibration of the fans, but happens every time at boot when fan2go is started.

To Reproduce
Steps to reproduce the behavior:
Start fan2go.

Expected behavior
My expectation would be that the fans go directly to the PWM set by the control scheme...

Desktop (please complete the following information):

• Distro: Gentoo
• uname -a: Linux hyperion 5.15.41-gentoo-x86_64 SMP Mon May 23 09:59:40 CEST 2022 x86_64 AMD Ryzen Threadripper 1950X 16-Core Processor AuthenticAMD GNU/Linux
• sensors -v: sensors version 3.6.0 with libsensors version 3.6.0
• fan2go version: 0.7.0 (latest stable)

[j4ncp]

BTW, I really like this software to control my slightly more complex cooling setup. I am a SW developer myself, but have little to no knowledge of Go, so I find it difficult to go into the code myself. In any case: thanks for creating fan2go!

[j4ncp]

Note that the described behavior is not really a dealbreaker or maybe not even a bug at all, but I was curious if this is intended or not, and if so, why.

[markusressel]

Hey @j4ncp 🤓

There definitely is a "startup sequence" that fan2go goes through for each fan, but it shouldn't take more than a couple of seconds.

When starting, fan2go goes through each fan and sets all PWM values in 255..0 to account for any "mappings" that might be present in the hardware or software implementation of a device. This was implemented to work around issues with the Commander Pro, where setting a PWM value of f.ex. 249 would result in a measured PWM value of 250 due to a conversion between 0-255 (8 bit integer) and 0-100 (percentage) in the linux driver for that particular device. See #64 for more info on that. While this could technically be done during the initial calibration process, the software implementation of a fan might change and I didnt feel like writing some migration path, so its currently done on every startup of fan2go. You can find the code here:

fan2go/internal/controller/controller.go

Line 450 in f101e2f

func (f *fanController) updatePwmMap() {

It should only take 255 * 10 ms, so about 2,5 seconds, regardless of fan count (all of them are measured in parallel).

[j4ncp]

Very interesting, thanks for the link. Indeed I happen to run a Corsair Commander Pro as well, and the situation @elais described there with the following words matches mine quite exactly:

In my situation I’m watercooling and the hardware controller allows me to attach multiple sensors and devices (fans, pumps, a flow indicator) that I do not have enough headers for fine grained control on my itx board.

I also do not have enough fan headers on my main board and no thermistor headers either, and I found the commander gives me exactly that, plus linux has support for it, hence I bought it, and it works quite well for me so far.

Regarding the pwm map update code you linked: I can confirm that it happens synchronously for all fans, but it definitely takes longer than 2.5s total. If it did take only that, I would probably not have noticed it. Anyway, if I find some time this week I might experiment a bit by adding debug statements so i can get at least some more precise timings. Any suggestions what else I could try to look into, where this might be coming from?

[markusressel]

Any suggestions what else I could try to look into, where this might be coming from?

Not really. I guess setting the PWM value takes a considerable amount of time on some devices, which makes creating this map very slow.

The only real fix for that would be to only do it once while initializing the fan for the first time. However, that could also cause some "support" issues down the line, when the implementation of a device driver changes. In that case it would need to be possible for the user to reinitialize a fan manually, but thats something I wanted to add anyway.

So, If you want and can, definitely do some additional testing and report here, but currently I don't think there is a way to solve this for good other than not creating this map on every startup.

PS: Its really funny that the algorithm that was specifically created to make this device work, does work with (what seems like) all devices except the one it was created for in the first place...

[j4ncp]

Ok, I have added the debug output to that loop, and indeed it seems that the whole process takes about 3 minutes and 30 seconds to go through all PWM settings, but only for the fans that are connected to the commander pro; I have also one fan connected to the mainboard directly and that is indeed done in about 2.5s. Interesting. Ok, so I guess this is just how it is for now, and it is not really a problem. However, I would be curious if others that use a commander pro have observed the same behavior. @elais, @eldorel, any comment?

[j4ncp]

Cool, thanks for taking the time to work on that!