Unable to set up my fans, fan2go.yaml settings seem to be ignored #324
Comments
|
OK, looks like after changing I did check the actual RPM values currently set, and they do seem to roughly correspond to where on the graph they would be, at that temperature. So I think the remaining issue is initialization.. |
|
OK, and now I was able to skip initialization as well, by adding this to every fan: pwmMap:
0: 0
255: 255I think the docs could be a little more clear on all of this, but perhaps I just didn't read them carefully enough. |
|
Actually, I spoke too soon. While the desired values reported in the log now with this |
Without a doubt, it's hard for me to explain all of this as I know too much about it (if you know what I mean). There are definitely some misunderstandings here, and a lot to unpack, I will get back to you after work 🤞 |
|
Hi @dinvlad , thx for your interest! Looks like you have a real spicy system to test fan2go on at your hands 😄
The
They are not, at least not entirely. If you set overrides for the PWM "limits", the long initialization should be skipped entirely. What is not skipped however, and is executed at each startup of fan2go is the calculation of the By specifying this: pwmMap:
0: 0
255: 255you are essentially telling fan2go, that this particular fan definition can only use the PWM values The "expected" pwmMap, would look like this (abbreviated for readability): pwmMap:
0: 0
1: 1
2: 2
....
254: 254
255: 255There is nothing wrong with specifying this in the config to skip the pwmMap initialization, except its a bit ugly.
I agree, that is precisely what should happen and that is what is (hopefully) implemented. If you see anything different, feel free to investigate and report, or even fix it 👍
Again about this: If you have suggestions on how to change the README to better reflect this, please open a PR and let me know! |
|
Thanks for clarification @markusressel , that makes sense.
Sadly, in my case it takes much, much longer than a second - I just measured and it was almost 11 minutes (!) I've now specified |
|
The reason this is done is because fan2go tries to automatically detect the best mode of operation. If we disable this feature by default, we might as well remove the entire logic, document the config and call it a day. This feature was added by request from fan2go users, I have never needed it myself. Some big brand "gaming" fan controllers just seem to work in weird and unexpected ways because... reasons 😄 I am not too keen on going that route yet, can we possibly figure out why it takes so long on your system? // check every pwm value
pwmMap := map[int]int{}
for i := fans.MaxPwmValue; i >= fans.MinPwmValue; i-- {
_ = fan.SetPwm(i)
time.Sleep(pwmSetGetDelay)
pwm, err := fan.GetPwm()
if err != nil {
ui.Warning("Error reading PWM value of fan %s: %v", fan.GetId(), err)
}
pwmMap[i] = pwm
}
f.pwmMap = pwmMap
PS: Nice trick using the anchors, I didn't even know viper supports this 😄 |
|
Thanks @markusressel - I did notice a delay even when running Looking at their code and associated issue (which mentions fan2go btw), it sounds like the controller is "slow" enough that they had to introduce a ~200ms delay between reads and writes: aleksamagicka/aquacomputer_d5next-hwmon#82 (comment) 256 * 200ms * 2 (read + write) * 4 fans is ~410s or ~7 mins, close to 11 mins I'm seeing (there's also likely a USB communication delay, to further account for the difference). So given that, would it be reasonable to introduce a config param to opt-out of PWM mapping (i.e. effectively assuming 0, 1, ... 255 -> 0, 1, ... 255 map)? Obviously, it would come with a disclaimer that fan control could be less accurate then.
|
|
I am wondering if it makes sense to detect these devices and use specific defaults for them. Do the fans have a specific platform name that's unique to this controller? Maybe we can come up with a system (f.ex. additional config files) to specify overrides for specific platforms so other people can benefit from the findings that were made in issues like this one 🤔 I would have to look into it, but I would guess that there are even more specific IDs for the controller exposed somewhere, if the platform isn't specific enough. |
|
These are just generic PWM fans (along with Noctua for the CPU), so I don't think we can detect the fans per se. But we can probably detect the controller (Quadro, in this case). I think potentially relying just on controller name (as reported by |
Describe the bug
I'm having trouble setting up my fan curves. I have set
minPwm,startPwmandmaxPwmfor each fan, but fans are still getting initialized on every run, and the curve values don't appear to follow what I wanted.To Reproduce
Steps to reproduce the behavior:
sudo /nix/store/84601dyyp25hqbq9a49kplnj76ljh1ji-fan2go-0.9.0/bin/fan2go -c fan2go.yaml -v(see the config below)Setting Fan PWM of ..., thenSaving pwm map to fan..., and finallyMeasuring RPM of ...Evaluating curvewithDesired PWM: 0, despite temperature readings from sensors being noticeable above theirminvalues.Expected behavior
minandmaxtemp readings, and the correspondingminPwmandmaxPwmvalues.Screenshots
My config:
Here's what the log said after the (very long) initialization (which happens on each run):
And here's what
fan2go detectshowed around that same time:And here are also the fan curves:
Desktop (please complete the following information):
uname -a:Linux homelab 6.11.3 #1-NixOS SMP PREEMPT_DYNAMIC Thu Oct 10 10:04:18 UTC 2024 x86_64 GNU/Linuxsensors -v:sensors version 3.6.0 with libsensors version 3.6.0fan2go version:dev(NixOS "unstable" version tag0.9.0)Additional context
I've tried various settings, setting the
steps:or sensor readings in degrees rather than milli-degrees. But nothing seems to matter - either I get fans set to 255, or 0.. And initialization takes a while each time.The text was updated successfully, but these errors were encountered: