Topic: Multiminer: A more efficient way to mine - page 2. (Read 23989 times)

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.

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?

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.