Multiminer: A more efficient way to mine

sakkaku

member

Activity: 70

Merit: 10

Quote from: ?? on ??

Trying to use this and all I get is:

multiminer.exe: error: no such option: --user

I can't see the --user option when I run multiminer -h either. How can it connect to a pool without a username and password?

--url http://username:pass@servername:8332

sakkaku

member

Activity: 70

Merit: 10

derp. reread the mmp protocol docs and it states you just need to trim it to 160 characters.

Quote

The format of this command is WORK data mask, where data is an 80-byte hex encoded (i.e. 160- hex-character) string. The data is exactly as if you ran a Bitcoin getwork() and truncated the "data" field to 160 hex characters.

Since that was easy I will just skip the WorkUnit class and pass it directly to the call...

Code:

[20/06/2011 19:57:35] Phoenix 1.50 starting...
[20/06/2011 19:57:35] Connected to server
MSG: There are now 1 connections             
MSG: Everyone welcome default to the pool!   
MSG: There are now 2 connections                
MSG: Everyone welcome sak to the pool!          
[1.40 Mhash/sec] [0 Accepted] [0 Rejected] [MMP]

Code:

Ready to accept connections.
[127.0.0.1:52514] "('login', ['default', 'default '])"
[127.0.0.1:52514] "('meta', ['device', 'Intel(R) Core(TM)2 Duo CPU     P7550  @ 2.26GHz'])"
[127.0.0.1:52514] "('meta', ['kernel', 'poclbm r95'])"
[127.0.0.1:52514] "('meta', ['version', 'Phoenix Miner v1.50'])"
[127.0.0.1:52514] "('meta', ['os', 'Darwin Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386'])"
[127.0.0.1:52514] "('meta', ['cores', '2'])"
[127.0.0.1:52514] "('more', [])"
[127.0.0.1:52514] "('meta', ['rate', '1438'])"
[127.0.0.1:52514] "('meta', ['rate', '1437'])"
[127.0.0.1:52514] "('meta', ['rate', '1507'])"
[127.0.0.1:52514] "('meta', ['rate', '1482'])"
[127.0.0.1:52514] "('meta', ['rate', '1507'])"
[127.0.0.1:52514] "('meta', ['rate', '1515'])"
[127.0.0.1:52527] "('login', ['sak'])"
[127.0.0.1:52514] "('meta', ['rate', '1430'])"
[127.0.0.1:52514] "('meta', ['rate', '1519'])"
[127.0.0.1:52514] "('meta', ['rate', '1652'])"

AWWW YEAH. I wonder if it even worth splitting the getworks like in the multiminer? When I point my 5870s at it they chew through more requests like mad.

sakkaku

member

Activity: 70

Merit: 10

Does anyone know where it calls onWork in WorkProvider? I am trying to figure out what it does to transform the getwork request to be consumed by miners but am stuck.

I am trying to write another mmp server implementation for fun and I can't find what it does to transform the getwork call from jsonrpc. I am currently using python-bitcoinrpc (https://github.com/jgarzik/python-bitcoinrpc) if that makes any diff.

(to speed things up I modified workunit sans the provider argument until I figure out what is going on underneath)

I get data with a length of 256 from bitcoind, workunit looks like it wants a length of 80 >_<

Druas

member

Activity: 78

Merit: 10

Anyone know of any pools that support this protocol?

jedi95

full member

Activity: 219

Merit: 120

Quote from: bitminer on May 12, 2011, 08:29:58 PM

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.

bitminer

newbie

Activity: 39

Merit: 0

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?

pwnyboy

full member

Activity: 125

Merit: 100

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:

https://bitcointalksearch.org/topic/flexible-mining-proxy-5506

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

newbie

Activity: 39

Merit: 0

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?

BitLex

hero member

Activity: 532

Merit: 505

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.

M4v3R

hero member

Activity: 607

Merit: 500

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 Cheesy

kindle

member

Activity: 84

Merit: 10

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?

BitLex

hero member

Activity: 532

Merit: 505

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.

pwnyboy

full member

Activity: 125

Merit: 100

@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?

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: CFSworks on April 03, 2011, 06:14:22 PM

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.

CFSworks

member

Activity: 63

Merit: 10

Quote from: martok on April 03, 2011, 03:46:28 AM

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.

martok

full member

Activity: 140

Merit: 100

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

member

Activity: 63

Merit: 10

Quote from: jgarzik on April 02, 2011, 04:42:13 PM

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

https://bitcointalksearch.org/topic/bitcoin-binary-data-protocol-for-mining-monitorblocks-etc-3493

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.

Quote from: martok on April 02, 2011, 05:19:34 PM

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

full member

Activity: 140

Merit: 100

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?

jgarzik

legendary

Activity: 1596

Merit: 1091

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

https://bitcointalksearch.org/topic/bitcoin-binary-data-protocol-for-mining-monitorblocks-etc-3493

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

full member

Activity: 140

Merit: 100

Quote from: CFSworks on March 31, 2011, 02:23:06 AM

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.

Topic: Multiminer: A more efficient way to mine (Read 23989 times)