Hi,
I was hopeing to use the "balance" or "load balance" strategy so that I can make my miner mines at different pools to even out the luck factor.
However, it never worked on my Terraminer... Even after I set the "balance" option or "load balance", the stupid Terraminer still keeps on mining at the "priority 1" mine only ......
Can anybody teach me how to fix it so that I can have my terraminer mining at multipools???
I was hopeing to use the "balance" or "load balance" strategy so that I can make my miner mines at different pools to even out the luck factor.
However, it never worked on my Terraminer... Even after I set the "balance" option or "load balance", the stupid Terraminer still keeps on mining at the "priority 1" mine only ......
Can anybody teach me how to fix it so that I can have my terraminer mining at multipools???
Cointerra uses cgminer, in cgminer's README doc there is info on loadbalancing. http://ck.kolivas.org/apps/cgminer/README
Code:
LOAD BALANCE:
This strategy sends work to all the pools on a quota basis. By default, all
pools are allocated equal quotas unless specified with --quota. This
apportioning of work is based on work handed out, not shares returned so is
independent of difficulty targets or rejected shares. While a pool is disabled
or dead, its quota is dropped until it is re-enabled. Quotas are forward
looking, so if the quota is changed on the fly, it only affects future work.
If all pools are set to zero quota or all pools with quota are dead, it will
fall back to a failover mode. See quota below for more information.
The failover-only flag has special meaning in combination with load-balance
mode and it will distribute quota back to priority pool 0 from any pools that
are unable to provide work for any reason so as to maintain quota ratios
between the rest of the pools.
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.
---
QUOTAS
The load-balance multipool strategy works off a quota based scheduler. The
quotas handed out by default are equal, but the user is allowed to specify any
arbitrary ratio of quotas. For example, if all the quota values add up to 100,
each quota value will be a percentage, but if 2 pools are specified and pool0
is given a quota of 1 and pool1 is given a quota of 9, pool0 will get 10% of
the work and pool1 will get 90%. Quotas can be changed on the fly by the API,
and do not act retrospectively. Setting a quota to zero will effectively
disable that pool unless all other pools are disabled or dead. In that
scenario, load-balance falls back to regular failover priority-based strategy.
While a pool is dead, it loses its quota and no attempt is made to catch up
when it comes back to life.
To specify quotas on the command line, pools should be specified with a
semicolon separated --quota(or -U) entry instead of --url. Pools specified with
--url are given a nominal quota value of 1 and entries can be mixed.
For example:
--url poola:porta -u usernamea -p passa --quota "2;poolb:portb" -u usernameb -p passb
Will give poola 1/3 of the work and poolb 2/3 of the work.
Writing configuration files with quotas is likewise supported. To use the above
quotas in a configuration file they would be specified thus:
"pools" : [
{
"url" : "poola:porta",
"user" : "usernamea",
"pass" : "passa"
},
{
"quota" : "2;poolb:portb",
"user" : "usernameb",
"pass" : "passb"
}
]
This strategy sends work to all the pools on a quota basis. By default, all
pools are allocated equal quotas unless specified with --quota. This
apportioning of work is based on work handed out, not shares returned so is
independent of difficulty targets or rejected shares. While a pool is disabled
or dead, its quota is dropped until it is re-enabled. Quotas are forward
looking, so if the quota is changed on the fly, it only affects future work.
If all pools are set to zero quota or all pools with quota are dead, it will
fall back to a failover mode. See quota below for more information.
The failover-only flag has special meaning in combination with load-balance
mode and it will distribute quota back to priority pool 0 from any pools that
are unable to provide work for any reason so as to maintain quota ratios
between the rest of the pools.
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.
---
QUOTAS
The load-balance multipool strategy works off a quota based scheduler. The
quotas handed out by default are equal, but the user is allowed to specify any
arbitrary ratio of quotas. For example, if all the quota values add up to 100,
each quota value will be a percentage, but if 2 pools are specified and pool0
is given a quota of 1 and pool1 is given a quota of 9, pool0 will get 10% of
the work and pool1 will get 90%. Quotas can be changed on the fly by the API,
and do not act retrospectively. Setting a quota to zero will effectively
disable that pool unless all other pools are disabled or dead. In that
scenario, load-balance falls back to regular failover priority-based strategy.
While a pool is dead, it loses its quota and no attempt is made to catch up
when it comes back to life.
To specify quotas on the command line, pools should be specified with a
semicolon separated --quota(or -U) entry instead of --url. Pools specified with
--url are given a nominal quota value of 1 and entries can be mixed.
For example:
--url poola:porta -u usernamea -p passa --quota "2;poolb:portb" -u usernameb -p passb
Will give poola 1/3 of the work and poolb 2/3 of the work.
Writing configuration files with quotas is likewise supported. To use the above
quotas in a configuration file they would be specified thus:
"pools" : [
{
"url" : "poola:porta",
"user" : "usernamea",
"pass" : "passa"
},
{
"quota" : "2;poolb:portb",
"user" : "usernameb",
"pass" : "passb"
}
]
Hope this helps.
