How can I efficiently switch pools on lots of miners at once?

[TwinTurbo]

So I have a few miners spread across three different physical locations. Each location has its own independent internet connection. Occasionally, I like to switch pools to mine different altcoin currencies, get better stability, better stats, whatever.

My machines all run on Windows and re-imaging and installing them is not an option. They all run CGMiner from batch files.

BAMT seemed appealing at one time, but seems the setup would be pretty laborious on 20 machines.

Ideally what I would like is something, perhaps a webpage hosted on a central computer, where I can proxy all of my miners through to whatever pool I specify on the server.

Any suggestions, ideas, etc are greatly appreciated.

[1714885569]

1714885569

[1714885569]

1714885569

[1714885569]

1714885569

[1714885569]

1714885569

[bigb0096]

Have you looked into the CGMiner API? https://github.com/ckolivas/cgminer/blob/master/API-README

I have a setup that uses the API to keep an eye on things for me. You can pull stats at intervals, monitor temperatures, change pools, etc. with the API.

If you look in the CGMiner codebase, you'll find a couple example programs for accessing the API. Alternatively, it's pretty easy to roll your own since it's a simple JSON interface.

[eleuthria]

If the pools all use Stratum, you could run a Stratum proxy on a central server.  Then whenver you want to move, just restart the proxy with a new pool address.  The miners should reconnect and now start sending work at the new pool.  You'll get a few rejects due to the miners submitting work from the prior server, but it shouldn't last very long.

[iCEBREAKER]

If the pools all use Stratum, you could run a Stratum proxy on a central server.  Then whenver you want to move, just restart the proxy with a new pool address.  The miners should reconnect and now start sending work at the new pool.  You'll get a few rejects due to the miners submitting work from the prior server, but it shouldn't last very long.

Won't the login name/password and format have to the be the same on all the pools?

EG: Some pools expect icebreaker.1 and some expect icebreaker_1.

Here's a hack I've considered using to get around this problem:  when you want to disable a pool, log in to that pool and change your worker password.  Then the miners can't connect so they'll move down to the next one.  To re-enable it, change the password back to the one set in your miners.

It would be nice if cgminer could change between scrypt to sha pools without restarting.  But Con might finally lose it and flip out if I requested that feature....   

[eleuthria]

Actually, I missed the part about altcoins.  As far as I'm aware, you can't swap cgminer from SHA256 to SCrypt altcoins without restarting it, so my solution wouldn't work anyways.

If it wasn't for Windows, I'm sure a quick shell/python script could be written to ping a central website for a signal to restart cgminer with different arguments.  It's possible with Windows too, but would be much easier in a Linux system.

[iCEBREAKER]

Actually, I missed the part about altcoins.  As far as I'm aware, you can't swap cgminer from SHA256 to SCrypt altcoins without restarting it, so my solution wouldn't work anyways.

If it wasn't for Windows, I'm sure a quick shell/python script could be written to ping a central website for a signal to restart cgminer with different arguments.  It's possible with Windows too, but would be much easier in a Linux system.

Good point.

The solution is to run two concurrent instances of cgminer, one for each type coin you wish to mine (scrypt and sha).

Break the worker passwords for the instance you wish to disable/idle, so the other active one gets full resources.  Reverse when profitability changes.

[ISAWHIM]

If you want to just log-in to multiple pools, it is easier. The program does all the work.

Use the "--load-balance" option. That will log-in to pool A, B, and C all at the same time... the ones "alive" will give work, and the dead ones will be skipped. The work spreads to any available thread/process/GPU. Distributing to the "fastest responding server", (AKA: Most efficient) with the largest portion of the load.

Not wise to switch from scrypt coins to sha256 coins. All that "resetting" of your cards will just cause errors, and make it hard to get a stable program running. The cards were not intended to constantly switch setup profiles. Run one computer with multi-pool scrypt, and one with multi-poo sha256.

[Trongersoll]

You could just train a bunch of Monkeys to push the buttons at the right time. (sorry, i couldn't resist)