fan: Split interval for actual/target duty

[crawfxrd]

Updating the actual duty is a detail of how the hardware control is implemented, and requires a short interval for its implementation.

Updating the target duty is a platform policy (the fan table), and does not require updating as frequently as the hardware control.

Because of this, the use of HEATUP and COOLDOWN needs to be re-evaluated.

HEATUP can be removed entirely. We want the quick response to rising temps without it instantly going to max from temp spikes. This is handled by the new hardware control, which limits how quickly the fan duty can change (3.9%/s).

COOLDOWN is still useful for hysteresis, to provide extra cooling as temps come down, but does not need to run for 10/20s it is set to. It is changed to 5s for all boards.

This should help address behavior of fans constantly turning on/off at point 0 threshold.

Test

• Check fan change is still responsive enough to handle changes in load
• Check fan no longer turns on/off constantly at threshold

[crawfxrd]

HEATUP/COOLDOWN values probably need to be reduced with this.

[leviport]

I think HEATUP and COOLDOWN do need to be reduced. On oryp12, I'm seeing the CPU start throttling before the fans reach full speed.

[crawfxrd]

Because I had tied the update interval together, HEATUP became effectively useless. Since these values actually use seconds for the unit again, their use need to re-evaluated.

HEATUP can probably be removed entirely. We want the quick response to rising temps without it instantly going to max from temp spikes. This is handled by the new hardware control, which limits how quickly the fan duty can change (3.9%/s).

COOLDOWN is still useful for hysteresis, to provide extra cooling as temps come down, but should use a smaller number than 10s/20s it is now doing.

[leviport]

Behavior on oryp12 seems good. Comparing to currently released oryp12 firmware, the performance is about the same under full load. I think there might be a smidge more bouncing between on and off around 50°C, but it's pretty close to the same.

[crawfxrd]

I think there might be a smidge more bouncing between on and off around 50°C

It should be about the same to released firmware:

• 20 intervals @ 250ms = 5s total
• 5 intervals @ 1000ms = 5s total

This is why I choose 5 for the new COOLDOWN value. I think the non-dGPU units (or really anything that was using COOLDOWN=10) will behave better at the on/off threshold.

Might be worth trying a slightly higher value to see if it mitigates this better. If so I could keep the board overrides for COOLDOWN.

(I think the better solution is a temperature-based hysteresis and not this time-based one, but I can't seem to get that to work correctly.)

[leviport]

It was very comparable. I just had two oryp12's sitting next to each other with s-tui running (shows fan RPM graphs) at idle. Both were hovering around 49-50°C, and the one with this EC had a slightly bumpier graph, with startup spikes:

(the units were further apart while idling, I just pushed them together for the picture)

When I previously commented above, the fans were running way more, but I re-applied thermal paste and it was nearly the same as the other model running he currently released. There was a bit of air on the CPU die, so cooler contact was not ideal. I think that was partially to blame for the throttling I saw.

[crawfxrd]

What's the intervals on those fan runs?

I could add a timeout so that when fans turn off, they stay off for a certain amount of time.

[leviport]

The light/dark bars are 2s intervals. The fan graphs are the two on the bottom.

[crawfxrd]

I'll leave the on/off issue for later (again). The important thing here is separating the hardware control from setting the target duty so that manual fan control can be implemented.