Yes, GGMiner has many options for changing your pool management. You simply add multiple pools into your command line or config file, and then choose which option you like best:
--balance Change multipool strategy from failover to even share balance
--load-balance Change multipool strategy from failover to efficiency based balance
--rotate <arg> Change multipool strategy from failover to regularly rotate at N minutes (default: 0)
--round-robin Change multipool strategy from failover to round robin on failure
MULTIPOOL
FAILOVER STRATEGIES WITH MULTIPOOL:
A number of different strategies for dealing with multipool setups are
available. Each has their advantages and disadvantages so multiple strategies
are available by user choice, as per the following list:
FAILOVER:
The default strategy is failover. This means that if you input a number of
pools, it will try to use them as a priority list, moving away from the 1st
to the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it will
move back to the higher priority ones.
ROUND ROBIN:
This strategy only moves from one pool to the next when the current one falls
idle and makes no attempt to move otherwise.
ROTATE:
This strategy moves at user-defined intervals from one active pool to the next,
skipping pools that are idle.
LOAD BALANCE:
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
an example. i want to always hash with 1ghash on deepbit (god forbit!) , 3 ghash on slush , 5ghash on another pool.
in case of the "other pool" goes off , the 5ghash to be distributed among the 2 previous pools. the detail on that is the hash limit. i havent seen that anywhere (or i've missed it)
IIRC, the only way to do this is to add 1 worker for Deepbit, 3 workers for slush, and 5 for any other pool, and then do a --balance scheme. Each worker will get 1/9 of your shares, or close to it. If slush goes down, then those 3/9 workers would go down, and your hashrate would be split over 6 workers now, not 9. The remaining 6 workers would then be hashing at a faster rate. I don't know of any way how to limit a pools hashrate any other way, but I also don't know why you'd want to.
