cgminer multi-pool change management strategies

[HyeEm]

I'm wondering what the optimal cgminer change management strategies are for multi-pool mining.  I currently mine on slush's and bitminter.  Specifically, my questions are:

1- Is it better to mine exclusively on 1 pool and keep the second as a fail-over only in case of issues with first, or to distribute the mining effort across 2 pools?

2- If one wants to mine on both pools simultaneously, then what are the differences between the following settings, and what's the current thinking on which is better?
     1: Round Robin
     2: Rotate
     3: Load Balance
     4: Balance


Apologies if there's already a thread on this.  Thanks.

[1714586790]

1714586790

[1714586790]

1714586790

[1714586790]

1714586790

[1714586790]

1714586790

[1714586790]

1714586790

[Kalen]

I've been doing slush as main, and failover to other ones just in case there is a problem.

After mining for a weekend, taking my stats and comparing how I might have done elsewhere or under another payout system, slush always seems to win with the 2% fee as opposed to 3-5% elsewhere.

[HyeEm]

Yes, I like slush's pool as well. 

My question is more to determine if there are benefits to mining on more than 1 pool at the same time, such as getting better overall throughput/shares, getting better payout from 2 pools combined  versus just 1, somehow gaming the "last n shares" formulas that many pools use, etc.

[kislam]

Hi,

Once you find a pool you like, there is no need to switch to other pools unless your preferred pool is down. Different multipool strategies do not usually give better overall hashrates, in my experience. Over the long run it averages out. Ideally, you should have at least 2 or more backup pools and set them as failover options in case the preferred pool goes down. CGMINER will automatically switch back to your preferred/higher priority pool when it comes back up if you keep the default settings (multipool strategy: failover).

CGMINER will send shares to preferred pool as well as backup pools if it finds that the preferred pool is lagging. If you do not want this, then set --failover-only option, which means shares will be submitted to backup pools ONLY if preferred/higher priority pool is down.

As an alternative, you can try the Load Balance strategy for a day or two to see if that gives you better results. What this does is try to get the best of all your pools so that no work is wasted. Fast pools get most of the work, while other pools take up the slack if preferred pool is lagging. But honestly speaking these days the major pools are quite robust, and won't give you much problems unless they are being DDOSed.

Best thing is to just try the different strategies one by one and see for yourself. Be sure to test all strategies before difficulty changes otherwise total earnings will not be consistent.

[laris2]

Hi,
I've managed to get the best results with a failover-only. The balancing options were not satisfactory for me in-terms of checking how my miner is performing, through pool API's.