I seem to remember the Avalon4 has an optimizer built in, where you can give it a hashrate and it'll iteratively drop the power until it finds the lowest stable point? We'll probably integrate an autotuning feature like that into it. If we can write an autotuning driver that can tune per board will be pretty great too.
I'm not sure if we're gonna have an input power measurement on there or not. Shunt measurements to take away from system efficiency - sure it's maybe a quarter percent of waste, but... yeah that's actually probably okay.
I think trying to find an optimal operating point based on power efficiency will pretty much always end you up at the top stable clock of the bottom possible voltage? If your only parameters are operating cost and hashrate you'll always end up finding the highest clock available at the highest efficiency voltage setpoint available. Being able to say "get me the most hashrate for this maximum power" or "get me the least power for this desired hashrate" are going to be different problems, but not difficult to solve.
Unfamiliar with the Avalon4, so I have no comment on it.
My follow on comments apply to the BM1382 (S3's and C1's) as I haven't started my testing on the BM1384's (S5's) which I'm more than willing to share when completed, if desired.
S3 hash boards are usually always stable @ .65 CoreV but not at clock rates approaching 150MHz. The limiting of clock rate limits profitability.
S3's @ .68 CoreV and 150MHz +- one clock setting seems to be the "sweet spot" from a electrical cost versus revenue standpoint.
I'm guessing this is due to a number of factors:
- board manufacturing tolerances due to variances in discreet passive components, resistor/cap tolerances, circuit trace tolerances, intertrace variances in capacitance, ground plane capacitance, etc . . . . .
- the CoveV/hashrate is not, necessarily, a smooth linear or exponential curve
- and active component (hash chip, LDO, etc.) manufacturing tolerances due to variances in a plethora of things at the wafer level
Having said the above there can be anomalous CoreV/clock rate combinations that provide, on a hash board by hash board basis, above "normal" net profits due to "quirks" in board/chip combinations.
This is why I would favor the calculations happening at the board level versus the driver level, cuz' each board is different (as is every hash chip chain on a particular board for that matter).
I also lean towards doing this at the board level to obviate the need for a special or "one off" branch in the cgminer/bfgminer source.
I was thinking more of the ability to set a flag (autooptimize=1/0, true or false ?) at cgminer/bfgminer run time if the appropriate hardware was detected after hotplug detection.
Implementing this flag architecture would allow the user to let the board figure it out or let the user "force" settings per their whims.
I think that the majority of the time the "optimal operating point based on power efficiency will pretty much always end you up at the top stable clock of the bottom possible voltage" is a true statement at the machine level, but on a fairly frequent basis there will be odd anomalous and/or deviant CoreV/MHz combinations at the board level/chip chain level that provide more optimal profits/performance.
With multiple boards in a machine there is a high likelihood that some boards/chip chains are going to be high performers and some not so much. If CoveV/MHz optimization is done at the driver level then all the boards running off that instantiation of cgminer/bfgminer will run at the least common denominator. If one board in many deteriorates faster than the others the entire machine's performance will suffer needlessly.
Over time components (active and passive) will deteriorate/change values. By definition, the interaction of those component deteriorations will cause a shift in the optimal CoreV/MHz operating point. Because one does not know which components are deteriorating, at what rate, and their effects on circuit performance a "self-healing" design reduces human interaction and assures optimal device operation in real time.
Just thinking "out loud".
