Mujina Allocation Strategies

[tronsington]

Thinking about miner-level power budgeting

MIP-0001 defines target_power_w per board, but there's no way to just say "run at 500W total" and have the daemon figure out the distribution. Wanted to open a discussion on how that should work.

The basic shape seems pretty clear: a miner-level /target_power_w and a /target_temperature_c at the root, acting as independent ceilings the daemon enforces. Write null to either one to remove the constraint, same as any other setpoint.

The more interesting question is how the daemon distributes the budget across boards. Imagine you have two S21s and two S19s connected to the same Mujina instance. The S21s are newer and more efficient, so intuitively Mujina should prioritize running those first and only bring the S19s online as budget allows or as the user needs more hash rate.

A few strategies worth considering:

Efficiency first: load the most efficient board first (by J/TH), spill into the next as budget allows. This is the behavior described above.
Thermal first: prioritize boards that can sustain the highest temperatures, maximizing heat output rather than efficiency. Useful if you're using the miner as a heating source to supplement a furnace or boiler. In that case a less efficient board that runs hot is doing exactly what you want.
Proportional: each board gets a share based on its rated max wattage.
Equal: split evenly, simple as it gets.
Manual: daemon stays out of it, you set each board yourself. Basically what we have today.
Efficiency first seems like the obvious default, but it requires the daemon to have some model of each board's efficiency, which gets interesting when you factor in that efficiency varies with temperature and load, not just rated specs.

Curious what others think and whether this matches the kind of control people would want.

[rkuester]

A miner-level target_power_w makes sense to me. I actually had an aggregate collection in an earlier draft of MIP-0001 #57 for miner-wide things like this: aggregate hash rate, aggregate power draw, all in a collection like /miner. I pulled it to keep the writeup simple, but target power fits there.

For what it's worth, MIP-0001 isn't meant to enumerate every node in the tree or every value the API exposes. It's mainly about how the tree works (paths, setpoints versus measurements, the cascade). A node not showing up in the document doesn't mean it's not in the schema, just that I didn't use it as an example.

For target_temperature_c, what are you picturing that would do? I want to make sure I'm imagining the same semantics.

The distribution question is interesting. I've talked before about the Scheduler component in Mujina, and its central role in allocating work according to policies. Efficiency-first sounds like it should be one of those policies.

There's a line somewhere; however, where I think things won't belong in the Scheduler. Pushing your thermal-first case further: imagine boards routing heat to different physical zones, holding a target temperatures in each. Once it gets complicated and deployment-specific, I think it's better that Mujina focuses on exposing the right knobs through the API, and a higher-level program that actually knows the installation does the orchestrating. Handle common policies in the daemon, keep system-specific stuff above Mujina.