Post
Topic
Board Mining software (miners)
Re: bitHopper: Python Pool Hopper Proxy
by
toliman
on 26/08/2011, 06:07:23 UTC
just a bit of a blank ended question, and i've only read 1/10 of the thread, because, 6 hours time to read one thread ... (sigh.)

do any of the schedulers allow load-balanced/parallel pool usage ?

i.e. 2 pool types interleaved so that while you might be on mine_slush and their rotations/slice priorities, it will also interleave another thread with a mine_charity or mine_deepbit thread ?
it would probably be easier to work with the pool categories in parallel, so that each connected miner, would be handling various packets, and shared pools at the same time. it does complicate the proxy nature of bH, but this would work if each share were equal in payload or there were metrics to use on each share/packet. it would possibly require a more advanced metric measurement of the size/difficulty of the work, as well as a few metrics for the minimum rate for each pool type, and a way to rate-limit work.

The more i think about it, the less it seems practical, except in the cases where you want to maintain goodwill with pool operators by contributing 1 out of every 4 shares, instead of 1 out of every 100 or 500 shares, or limit it down to 1 : 10, etc.

it would also reduce the 'surge' phenomenon, where combined rates halve or decimate once the minimum share dividend has been reached, it also allows for acceleration and deceleration over time for PPS/Proportional 'surges' where a new block will reset the current shares. on the flipside, if aggressive pools implemented duration-based timeouts or a last-man-standing proportional system, to prevent surges, which is not as difficult to implement as a routing metric, this approach would be designed to stop that kind of ban taking place, as long as enough shares were being sent to keep that 'window' open.

without a real metric routing protocol, modifying an existing scheduler could probably do this on a 1:10 share basis, maintaining a minimum work rate of say, 80mh/s on one, or two "non-hoppable" pools and still continue with the PPS/Prop/last-man-standing pool hopping to maintain a shared dividend.

or is this idea just silly for reasons i can't fathom, namely that routing metrics are ridiculously difficult and complicate things ?