Multiminer: A more efficient way to mine

[CFSworks]

Not sure if this will be useful to anyone but me...
I've developed a lot of this stuff for my own in-house use, and in the spirit of being open and transparent, have decided to release this to the general Bitcoin public.

I've designed my own push-based Bitcoin mining protocol. It's called MMP (for Multiminer Protocol) and is a simple line-based protocol that operates over TCP. The idea is that miners don't have to ask for work repeatedly because the server informs clients when new work is available. It's a little bit more efficient than long-polling, which requires a separate connection to wait on the long-poll (I could be wrong; I didn't really study long-polling too in-depth) since everything operates over a single message-based TCP connection. It's also considerably more efficient than JSON-RPC: Requesting more work from the server requires 6 bytes from the client and 170 from the server. (Compare this with 47/605 for JSON-RPC... and that's not counting HTTP headers)

Since nobody uses MMP right now except me, I've created a gateway to Slush's mining pool at mmpgateway.mooo.com on the standard MMP port 8880.
It finally offers push-based work from Slush's pool. (But please be gentle, this is a friend's home connection; and no, I don't log your password or feed you my own work)
I realize there are other pools out there, and while I'd like to provide a gateway for every one, I don't have the resources. I picked Slush's because it's large and in need of a push-work solution at the moment, but if you operate a pool, I will gladly help you add MMP support if you ask.

MMP was primarily designed for use in my more-serious project, Multiminer Server which is designed to maintain only one outbound connection to a mining pool (or locally-running Bitcoin client), and distribute smaller work units to miners. It's fairly easy to set up; here's a simple configuration to provide 30-bit work to local clients under the username/password "default":
multiminer.exe --mmp --host=mmpgateway.mooo.com --user=PoolUsername.worker --pass=workerpass --admin-user=default --admin-pass=default --mask=30

You can then connect MMP miners to the newly-running MMP server at localhost:8880 and watch them mine.
Also, if you add --web-port=8882, you can use it as an old-fashioned RPC server (which doesn't yet have long-polling) at localhost:8882

Finally, I have poclbm-mmp, which is a slightly-modified version of poclbm that adds an option to connect to MMP servers.
You can connect it to the running multiminer server with this command:
poclbm.exe --mmp --host=localhost --port=8880 --user=default --pass=default -d 0
Or directly to the Slush gateway (which should provide for less stale work, and no polling required):
poclbm.exe --mmp --host=mmpgateway.mooo.com --port=8880 --user=PoolUsername.worker --pass=workerpass -d 0
poclbm-mmp continues to support old-fashioned JSONRPC if you remove the --mmp option.

[martok]

Interesting idea. Couple things:

What does this give over long polling exactly? From reading the protocol, a typical 5970 will still be sending lots of "more" commands as it processes the work then is notified about the new block.

Assuming one doesn't use your gateway, how would this tie into bitcoind? Client sends a more and multiminer passes that to bitcoind as a getwork to fetch the work? Or does your code generate work without going through bitcoind?

[CFSworks]

Interesting idea. Couple things:

What does this give over long polling exactly? From reading the protocol, a typical 5970 will still be sending lots of "more" commands as it processes the work then is notified about the new block.

Assuming one doesn't use your gateway, how would this tie into bitcoind? Client sends a more and multiminer passes that to bitcoind as a getwork to fetch the work? Or does your code generate work without going through bitcoind?

A typical 5970 would indeed send lots of "more" requests (tests with 5870s show they request more every 11 seconds or so) but it only needs to send a "more" request when it's getting low on unique hashes to try, since there is no way to get more than 2^32 hashes out of a single work block (without updating the timestamp) -- this same principle applies to getwork-based miners as well.
The primary advantage over long-polling is that it never has more than one connection open to the server. With long-polling, you need one connection open for the long-poll, and another connection to request additional work (however I didn't look at long-polling in depth; I could very well be wrong about this) - the added connections and overhead from HTTP can consume a lot of server resources, so the benefit is mainly toward pool operators struggling to optimize for bandwidth.

Multiminer has JSONRPC support, but only for genuine Bitcoin RPC (as it depends on the getblockcount call in order to function) - but multiminer keeps a stockpile of work (this defaults to 0x200000000 hashes but can be changed with multiminer's setconfig() RPC call) and subdivides down to get small enough work for a client. If the client's mask is 30-bit, and multiminer has a stockpile of two 32-bit units, it will split one of them into 31-30-30-bit work units and assign one of the 30-bits to the clients. The idea is that the miners get smaller work at a time and they don't have to risk tossing as many perfectly-good hashes that could go to another miner. The benefit is especially apparent with slow CPU miners that don't need a full 32-bit unit to function.

In the future, I plan to have Multiminer actually do timestamp-fudging to create work without going through bitcoind; whether I do this sooner or later depends on whether people want this or not.

[martok]

more efficient than long-polling, which requires a separate connection to wait on the long-poll (I could be wrong; I didn't really study long-polling too in-depth) since everything operates

set up; here's a simple configuration to provide 30-bit work to local clients under the username/password "default":
multiminer.exe --mmp --host=mmpgateway.mooo.com --user=PoolUsername.worker --pass=workerpass --admin-user=default --admin-pass=default --mask=30

You can then connect MMP miners to the newly-running MMP server at localhost:8880 and watch them mine.

So is it possible to run multiminer without using your gateway? IE run multiminer which connects to a local bitcoind and in turn has local clients connecting to via MMP?

I think one advantage to your setup may just be the fact that for solo miners, one could see which miners are connected, their hashrates etc. As someone who mines (solo) but using multiple machines, it's difficult to keep track of when a miner goes down for whatever reason.

[jgarzik]

A more efficient binary data protocol for this has already been implemented:

     http://bitcointalk.org/index.php?topic=3493.0

This is what I plan to add to bitcoind, as it supports multi-mining / push mining / block broadcasting and a host of other applications.

The linked implementation is usable in production already.  Patches for cpuminer will be forthcoming.  If you could add BDP support to poclbm, that would be great!

[martok]

Hi,

Ok I got multiminer working on a solo miner. poclbm-mmp is about 1mhash slower per 5970 core though. Any idea why this would be?

[CFSworks]

A more efficient binary data protocol for this has already been implemented:

     http://bitcointalk.org/index.php?topic=3493.0

This is what I plan to add to bitcoind, as it supports multi-mining / push mining / block broadcasting and a host of other applications.

The linked implementation is usable in production already.  Patches for cpuminer will be forthcoming.  If you could add BDP support to poclbm, that would be great!

Interesting. I'll give some thought to adding BDP support to Multiminer, in addition to long-polling (both on Multiminer's frontend and backend) - no promises for anything soon, though, as I have something else occupying my time at the moment.

Hi,

Ok I got multiminer working on a solo miner. poclbm-mmp is about 1mhash slower per 5970 core though. Any idea why this would be?

Are you using vectors? With poclbm-mmp, I had to change the OpenCL kernel's vector code slightly to make it compatible with work that is potentially smaller than 32-bit. If you are using 32-bit work, you should be able to drop in the old poclbm kernel (BitcoinMiner.cl) and put it in poclbm-mmp to get the speed back.

[martok]

Thanks, using -b32 rather than -b30 and reverting BitcoinMiner.cl gave back the speed. Any advantage to the smaller workunits? I mean is it worth giving up a mhash?

[CFSworks]

Thanks, using -b32 rather than -b30 and reverting BitcoinMiner.cl gave back the speed. Any advantage to the smaller workunits? I mean is it worth giving up a mhash?

For CPUs the efficiency benefit is quite apparent, since it takes them longer than 10 minutes to do 2^32 hashes (i.e. they are less than 7158 khps) so giving a cluster of CPUs smaller units means you risk tossing less hashes when the block changes.
For GPUs, it is (at least in theory) better as well, but due to some inefficiencies in the way poclbm switches work (which BitcoinPool's modified poclbm may or may not have solved; I didn't look into it yet) there isn't much benefit to doing so. The -b flag is (mostly) intended for CPU clusters.

Although, I do appreciate you trying different values and providing some feedback on the speed changes. This benefits me as well.

[FairUser]

For GPUs, it is (at least in theory) better as well, but due to some inefficiencies in the way poclbm switches work (which BitcoinPool's modified poclbm may or may not have solved; I didn't look into it yet) there isn't much benefit to doing so. The -b flag is (mostly) intended for CPU clusters.

Poclbm-mod works through the entire getwork before asking for more.  It also support long-polling, which means it opens a connection to the server on a side-channel and waits for the server to send a getwork back (which happens when the block changes).  We too noticed that poclbm pulling a getwork every 10 seconds which wasn't efficient.  I'm glad to see that someone else also understands this.

[pwnyboy]

@CFSworks/jedi95, thank you _very_ much for writing and releasing this.  I saw one of you mention in another thread that you would soon release the code for the web status page for your own Multiminer setup after some code clean-up.  Any update on that?

[BitLex]

i am using mutliminer-1.4 with phoenix for a few days now,
worked pretty good, actually i get less stale shares on deepbit than connecting miners seperately (0.6% with MM vs 1.2% without).

in the last 2 days though all miners stopped working with an empty-queue-msg at some point and didnt start again 'til i restart multiminer.
noticed the first stop a bit late, so the miners didn't do anything for ~7hours, second time i gladly noticed it after ~1hour.
i've no idea why it happens, but it's kinda sucky.

[kindle]

Seems like its working when solo mining, however I am not to sure what extent it is working well with the new 0.3.21 version of the bitcoin client. I haven't been successful in solving a block yet. Has any one solo mined and solve using this yet?

[M4v3R]

I just wanted to jump in and thank you for the MultiMiner. It works great, and finally I can monitor my rig on my iPhone

[BitLex]

well, i finally gave up using it, after it just stopped working again twice,
i don't want my GPUs being idle for hours and i just can't watch them all the time.

[bitminer]

I would like to mine solo. Phonix 1.46 running on my mining rigs and I would like to see all important infos (hashrates etc.) of the my miners in one place.
Is "multiminer" the best aviable tool to monitor multiple miners and share the work between them?

[pwnyboy]

It's my understanding that you can't get that information from multiminer - it's contingent upon the release of a certain python-to-html generation script (or the coding of your own script) which the developers have not yet released.  Not sure why.

There is another option, cdhowie's flexible mining proxy:

http://bitcointalk.org/index.php?topic=5506.0

Note that I am still not yet able to use it on a CentOS 5.5 based machine, it generates too many stale shares because long polling is broken, although others seem to have success with it.

[bitminer]

I've found a bug:
if I stop bitcoin and I check the hashrates of my miners via JSON-RPC request I see about 20% slower rates than their maximum however their real hash rates are 0.
I don't know much about python. Has anyone any idea how to fix this?

 

[jedi95]

I've found a bug:
if I stop bitcoin and I check the hashrates of my miners via JSON-RPC request I see about 20% slower rates than their maximum however their real hash rates are 0.
I don't know much about python. Has anyone any idea how to fix this?

 

This is a bug in Phoenix. Right now it only displays 0 Mhash/sec in the GUI. It still continues to push the last hashrate in the META. It will be corrected in the next version.

[Druas]

Anyone know of any pools that support this protocol?