Thermal management

[jayrmotta]

Hi there 👋

I want to work on the issue #9 so I've been doing research and my idea is to implement a PID controller that would give me a "thermal pressure" to feed into actuators to adjust fan speed and frequency.

In my initial testing the BitAxe Gamma shooted to 90+ degrees celsius even with the fan speed being set to 100%. In my experience running AxeOS for the last year I had to manually adjust fan speed, frequency, and voltage to find a hashrate I was happy with, produced acceptable noise, and worked well.

I thought we could have a state machine with the following states:

1. Normal: fan speed at minimum and frequency at maximum;
2. Cooling: fan speed between 0-100% according to the thermal pressure and max frequency;
3. Throttling: fan speed at 100% and frequency would be reduced step by step;
4. Emergency: fan speed at 100% and minimum frequency.

In my research changing voltage is a bit more dangerous than fan speed and frequency, since the current implementation sets fan speed to 100% by default and I still had high temperature the state machine would put me into cooling or throttling mode to lower the temperature.

The principle is that a user would probably desire their device to produce the least noise, deliver max performance, and work continuously, but given the technical constraints and environment the firmware will adjust the device's setting focusing on safety, comfort and then performance. The order of comfort and performance is a trade off, some people could accept louder noise if that gave them better performance, so maybe that's something we could offer as a config.

Reading the codebase I couldn't easily pinpoint where to place the new code, ideally this implementation should be generic and work with various devices, making a case for it to be placed agnostic to specific components (peripherals) or devices (boards), so I'm looking for guidance here as I don't know boards other than the gamma and if the parameters for this solution would work for all others. Maybe the fine tuning for things like the PID ratios, temperature threshold, etc, could be offered as "advanced" configs as well.

I'm happy to further elaborate in more lower level details of the implementation, but will stop here and let the questions and suggestions drive the discussion.

Thank you!

[rkuester]

You're 100% right to point out there's more to control on Bitaxe than just the fan. Perhaps there are multiple layers (maybe implemented with state machines) here: a simple controller that runs the fan at the minimum speed needed to maintain a given temperature, and another layer or layers above it that are managing frequency and voltage, with temperature and or the fan controller's inability to limit temperature as an input.

A quick detour with some background: the set of connected boards is given to a scheduler. The scheduler is where high-level policy is known—e.g, are hashing all-out at max efficiency, are we targeting a specific power consumption, are we idling, etc. The scheduler tells the boards—actually, abstract hash threads, of which a board might have several—what to do. A Bitaxe Gamma only has one thread.

Right now, the scheduler tells the board (via the thread interface) to either work all-out, or to idle. Coming soon, it will ask for specific power targets. The higher-level controller I'm imagining would manage frequency and voltage to meet these targets. (Basically, manage frequency and use the minimum voltage required. In all cases we want as much hash rate as we can get for the power we're using.) The reason the fan seems like a sub-controller is that pretty much needs to do the same thing in every case: keep the fan at the minimum speed to maintain temperature.

So—I picture these controllers as a part of the Bitaxe Gamma board module. I'd start simple: start with a fan controller; see how it goes. Then tackle the higher-level controller. Focus on getting it to work on Bitaxe Gamma. As it evolves and we have a desire to use it on other boards (e.g., another Bitaxe model), we can factor it out into components that both boards can use. I imagine this will be a good pattern to take for many things—start concrete for one board, and then we'll iteratively factor out shared components.

Feedback welcome! It's early and all these abstractions can be changed as we learn what works and what all the real requirements are.