Wattage and cost/watt is needed for those calculations. Since the units are non-standard and wattage changes per operation.
Yeah, I think I have to add at least cost per watt since people have different costs. The wattage should be calculated from the frequency and mode. At max stable frequency of 700Mhz, each unit (5 grid chips) consumes: 21watts (BTC mode), 22.8 watts (dual mode) and 2.2 watts (scrypt mode). So the I think the only thing that will be required is knowing the cost per watt (or Kw) of electricity. The rest is calculated.
The main idea is that cgminer could then select which of the 3 modes to use to maximize mining profit, without user intervention.
Might also want to allow a "Do not mine" list LUT. For times when POS-stalling coins are horribly inaccurate for "reward". Also, for "lotto-style" coins that the calculations for reward are never correct, due to poor calculations of the lotto randomness. (Those are coins with a "?" next to the block-rewards on CoinWarz. There are more losers than winners, but the value is calculated as an average of high/low, which is inaccurate to any actual value, at any point in time. While POS-stalling is when POS blocks boot-out any actual POW block rewards, because the POS causes a block-reset too fast, due to its low difficulty. Thus, cutting reward in half, as it still shows as a valid "block" for that hour, until the formula realizes it isn't a reward, then re-adjusts to a lower diff later. A lower diff that someone-else gets, if you hop off the coin.)
I am not sure I am following this, can you give me some more? Couldn't this be fixed by creating a server/deamon that provides a feed for a fictitious coin? The fictitious coin would have whatever attributes are required (to account for LOT style coins for example where an "average" may not be representative without taking into account variance). I was thinking that taking that part out of cgminer would be a good idea so that server feeds for new coins could easily be incoporated without having to mess with the cgminer code any further. Or am I missing your point?
Also, limiting high-diff coins, if you are a solo-miner and not a pool-miner. (Since hopping to a high-diff coin will be zero reward unless you actually stay until at-least one is found, which would be when the value is no-longer rewarding.)
I thought about doing something for solo mining, but the coding would be too much for right now; you would have to create a database of all alt-coins and be able to keep price/difficulty curves up to date for all of the coins . it would also make running on a low power embedded device like an rPi a real challenge. I would love to do this project, but I know my limits!
Is that working ok for these ?
