How about just pointing all smaller miners (like >550k?) to the small coins permanently? Have a short list of all coins sub 10 diff that are only mined by a very small subset of wafflepool miners. If you set the variable to low miner hashrate, I would think this should at least be too slow to jump and repeat the issue which caused you to discontinue mining low diff coins.
The issue is just the overhead of managing individual workers separately. Each endpoint (usw, use, eu) is currenly comprised of 4 physical servers each (12 total servers). Previously we were switching a single server at a time (based on hashrate for that server), but at this point, even a single server is too much (assume 800MH/s per server - even though theres some variance). The simple solution (although much more expensive) is to have 10 physical servers instead of 4 at each endpoint, essentially just subdividing a bit further, but this fails as well at some arbitrary time in the future, and really isn't an acceptable solution (I'd rather have something good, rather than taped together with a "well this will push the problem off til later").
But the first piece here is to figure out how much it will actually matter. I don't think for smaller coins we want to aim for anything faster than 1/2 their average block time (for this excersize, lets go with aiming for 30 seconds), or else we're just wrecking the coin too quickly. Hashrate also really doesn't matter that much, as the variance when dealing with a small portion of our pool isn't an issue.
And while typing out this reply, and trying to get hard data to paste, I think I've convinced myself
Here is a quick list of the coins we currently support, that are under 10 difficulty (mining-disabled currently), their difficulty, and the hashrate required to have an average block speed of 30 seconds.
name - diff: hashrate for 30s blocktime
digitalcoin - 9.04891019: 1.30 GH/s
philosopherstone - 8.56102751: 1.23 GH/s
luckycoin - 8.36572523: 1.20 GH/s
mincoin - 6.06047996: 867.65 MH/s
spots - 4.3518826: 623.04 MH/s
chncoin - 3.14754512: 450.62 MH/s
elacoin - 3.05901337: 437.95 MH/s
casinocoin - 2.81701341: 403.30 MH/s
cosmoscoin - 2.50721665: 358.95 MH/s
grandcoin - 2.18049873: 312.17 MH/s
franko - 1.79813971: 257.43 MH/s
diamond - 1.65509142: 236.95 MH/s
phoenixcoin - 1.56782297: 224.46 MH/s
stablecoin - 1.54614731: 221.36 MH/s
alphacoin - 0.84637737: 121.17 MH/s
bottlecaps - 0.67486716: 96.62 MH/s
As you can see, for the vast majority of these, we'd be needing to switch less than 1GHs (most less than 500MHs), 5-10% of the pool at current size.
For this next part, I'm going to make some assumptions that make sense to me, if someone has real data here, I'd love to see it, but they seem within the realm of reason.
Say these smaller coins are more profitable than a large coin 50% of the time (I think this is high), and are more profitable by 50% (also a bit high). And we switch 5-10% of our pool to aim for them (500MHs-1GHs). You're looking at a 1.25-2.5% boost to profit, without taking into consideration any of the context switching.
While I'm not certainly not against a 2% (or so) boost in profitability, the sheer cost of tracking all of these coins on all of the endpoints, and the cost of building something that accurately watches the hashrates and pushes the right amount on and off of those coins, doesn't seem like a great use of time (at least at this point).
Thoughts?
