Choose the most profitable algorithm sounds like a one-line program: calculate the expected return for each option, take the maximum, and run it. The interesting part is everything hidden inside expected.
MultiPoolMiner combines benchmarks, pool information and command-line miners to make those choices. I saved the project because it is a compact example of software controlling other software under changing conditions. Its estimates depend on both the local machine and information received from elsewhere.
A benchmark answers a local question: how much work can this hardware perform with this particular miner and algorithm? A pool estimate answers a different question about the value of that work. Multiplying compatible quantities can produce a revenue estimate, but neither input is timeless. A short benchmark can capture startup behavior rather than steady operation. A remote estimate can describe conditions that have already changed.
There is also no useful comparison between raw hash rates for unrelated algorithms. A larger number of hashes per second does not automatically mean a better result. The unit only becomes meaningful in relation to the work, rewards and costs associated with that algorithm. Comparing the display numbers alone is like comparing kilometers with liters because both happen to be large.
Now imagine two options whose estimated returns are almost equal. The ranking flips at every update. A controller that always follows the current maximum can spend much of its time stopping one process, starting another and waiting for useful work to resume. Each decision is locally consistent with the rule. The sequence is poor.
One possible response is hysteresis: require a meaningful advantage before switching away from the current choice. Another is a minimum dwell time. These are general controller design ideas, not guarantees that a particular setting will improve returns. Their purpose is to account for the fact that changing state has a cost.
A watchdog solves yet another problem. A process can still exist while failing to do useful work. Monitoring must distinguish a running program from a healthy miner, and it needs a recovery policy that doesn't itself create endless restarts. Logs become important because the final status alone may hide the sequence of events that produced it.
Finally, revenue and profit are different quantities. Electricity, fees, rejected work, downtime and settlement all change the result. An elegant selector can optimize the estimate it receives while the overall operation remains uneconomic.
The project interests me as a reminder that an optimizer is only as good as its measurements and its model of transitions. The maximum of a list is easy. Deciding whether that list describes the situation well enough to act on is the actual job.