Multipool - the pool mining pool (with source code)

[Mike 71]

I used this site

http://www.btcserv.net/bitcoin-calculator/

to calculate my 24 bitcoin earing, what should be match my earing here / efficiency.

But i recalculated right now, and it says .31 now, before 3 days it sayed .43 (same difficult was shown on the right side), so with .31 it seems fine.

[1713860276]

1713860276

[organofcorti]

I used this site

http://www.btcserv.net/bitcoin-calculator/

to calculate my 24 bitcoin earing, what should be match my earing here / efficiency.

But i recalculated right now, and it says .31 now, before 3 days it sayed .43 (same difficult was shown on the right side), so with .31 it seems fine.

Great link. Interesting.

It's giving you less for 24 hours now because it attempts to take into account the fact that new difficulty will start in a few hours. So it's still too low. Can you post your Mhps and copy/paste the first (summary) section of your stats?

[Multipool]

Why do I see no earnings for btcguild and for the other pools just after a very long time? Are you taking the funds from the pools manually?

Many pools have a waiting period before rounds are confirmed and rewards are calculated. The period is typically 120 blocks, which is ~20 hours. While btcguild and some other pools (but not all) display stats for rounds pending confirmation, those stats sometimes change midway through (rounds become invalidated), and that was messing with my database. So I only display full "earned" stats only for confirmed rounds for now.

What changed on wednesday in your utility calculations? mtred did really fine till Wednesday, then we started to just send 1 or 2 shares per block.
And what happend to all that eligius shares? That really hurt.
About profit, even if my stats look fine (efficiency 1.1), i havnt earend what i should have earned with standardvalue * 1.1. Not even 90 Percent of it. Maybe all those idle and RPC Probs one reason for that.

If you are comparing payouts to what you estimate what you would have made during the same time while solo/in a single pool, are you including the "pending" shares and the "solo" shares? When Multipool solves its own block, all the solo shares will be rewarded... proportionally .

Still tweaking optimal loads for the pools in rotation. Deepbit and btcmine bans appear to have expired. Also I seem to have figured out how to mine from slush without breaking load constraints. Apparently, slush only remembers the last 24 shares requested per miner, and any submitted shares older than that are rejected. Using more miners on rotation did the trick! Still tweaking mtred (might have set it at too restrictive!) and bitcoinpool.

In addition mtred earnings scrapper has apparently been broken last two days - the mtred status page format has changed and Multipool wasn't able to parse their rounds info. Once this fix is out, the "pending" mtred blocks will get merged into confirmed rounds.

I don't really care about showing utility/shares, but if you could publish the total shares it took the 'victim' pool solve the block our shares are from, that would be awesome. Although prob very hard. Are some of the shares getting grouped together with shares from other blocks?

Fine fine, nagging works. Here's a dump from the database of pool round total shares and timestamps. You can also get this info yourself from the pools' public stats pages.

[organofcorti]

Thank you very much Mr. Pool! Hope it wasn't too much of a hassle.

Cheers.

[Grinder]

Has anybody used this pool successfully with "Flexible mining proxy"? The proxy works fine with my 5 other pools, but this one is just completely ignored. It never logs any attempt at getting a share, even though it has the highest priority and both pool and workers are enabled. I don't get any error messages as far as I can see.

[nick5429]

Has anybody used this pool successfully with "Flexible mining proxy"? The proxy works fine with my 5 other pools, but this one is just completely ignored. It never logs any attempt at getting a share, even though it has the highest priority and both pool and workers are enabled. I don't get any error messages as far as I can see.

I've tried it, and get the same behavior you're seeing.  Being able to use Multipool as my primary and something else as backups is really the whole reason I found "Flexible mining proxy" appealing to begin with, so it would be great if someone were able to get this working!

[organofcorti]

I know this doesn't answer your question, but I'm using multiple instances of miners for backup and for load balancing. Works well.

[superweb]

Mining for 18 hours by about 280MH/s at multipool. Not enought to see if it's efective for me, but what I can see now is, that my stale rate is much higher than when I mined on single pool. Used to have it at about 0,5%, now with 52 stales from 3700 shares I'm at about 1,4%
Is this normal?
Using poclbm -v -w256 -f60 with 6870 at 1000Mhz core and 346Mhz RAM, backed up with "poclbm -f300" on deepbit for case of multipool problems. While the deepbit backup is getting only about 10MH/s, it's at 3 stale out of 350 shares.

[TeaRex]

Hello Multipool,

my total efficiency value suddenly jumped way up after today's difficulty change. Is your website script maybe not taking into account that older shares have to have their efficiency measured against the difficulty that was in place when they were submitted rather than the current value?

Regards TeaRex

[shamen]

I cant seem to connect any more

*edit* back upp. offline for about 2 hours for me there

[tekwarrior]

Mining for 18 hours by about 280MH/s at multipool. Not enought to see if it's efective for me, but what I can see now is, that my stale rate is much higher than when I mined on single pool. Used to have it at about 0,5%, now with 52 stales from 3700 shares I'm at about 1,4%
Is this normal?
Using poclbm -v -w256 -f60 with 6870 at 1000Mhz core and 346Mhz RAM, backed up with "poclbm -f300" on deepbit for case of multipool problems. While the deepbit backup is getting only about 10MH/s, it's at 3 stale out of 350 shares.

I got a lot of rejected shares too, but I noticed that the number of those fits my usual 2% + the solo shares perfectly (though I'm not sure if it's really the reason for that).

[iopq]

I'm getting these:
2011-06-24 12:36:14: Listener for "multipool": error: [Errno 10061] No connection could be made because the target machine actively refused it
2011-06-24 12:36:14: Listener for "multipool": Traceback (most recent call last):
2011-06-24 12:36:14: Listener for "multipool": File "BitcoinMiner.pyo", line 261, in longPollThread
2011-06-24 12:36:14: Listener for "multipool": File "BitcoinMiner.pyo", line 223, in request
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 898, in request
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 935, in _send_request
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 892, in endheaders
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 764, in _send_output
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 723, in send
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 704, in connect
2011-06-24 12:36:14: Listener for "multipool": File "socket.pyo", line 514, in create_connection
2011-06-24 12:36:14: Listener for "multipool": error: [Errno 10061] No connection could be made because the target machine actively refused it
2011-06-24 12:36:14: Listener for "multipool": Traceback (most recent call last):
2011-06-24 12:36:14: Listener for "multipool": File "BitcoinMiner.pyo", line 261, in longPollThread
2011-06-24 12:36:14: Listener for "multipool": File "BitcoinMiner.pyo", line 223, in request
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 898, in request
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 935, in _send_request
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 892, in endheaders
2011-06-24 12:36:14: Listener for "multipool": File "httplib.pyo", line 764, in _send_output
2011-06-24 12:36:15: Listener for "multipool": File "httplib.pyo", line24/06/2011 12:36:15, Problems communicating with bitcoin RPC

[Multipool]

Something's odd going on. While majority of the miners are doing fine, 8 of them are hammering the server at 10 getworks per second each and with few/zero submitted shares. They seem to have been doing fine in the past. Is there a new miner version out, or did I mess something up in the miner connection module? I haven't been changing anything in that area.

[Multipool]

Ok, the surge has passed. By the way, if your recent share submission rate is less than 40%, you will only get solo shares . Don't want to get the pool banned for DoSing getworks with no shares returned - this protection worked very well just now.

I cant seem to connect any more

*edit* back upp. offline for about 2 hours for me there

Server crashed after running out of memory. Spent some time optimizing the database - replaced a large number of hashtables with arrays - cut the memory usage in half. Also, bitcoind needs restarting occasionally - its memory footprint can grow larger with time than that of Firefox 3!

Hello Multipool,

my total efficiency value suddenly jumped way up after today's difficulty change. Is your website script maybe not taking into account that older shares have to have their efficiency measured against the difficulty that was in place when they were submitted rather than the current value?

Regards TeaRex

That's right. I thought I put the variable difficulty checks in place already, but apparently I didn't. The checks are up now, and all your efficiencies are accordingly back down. Are you sure you wouldn't rather be looking at 170% efficiency values, even if only imaginary ?

I can see now is, that my stale rate is much higher than when I mined on single pool. Used to have it at about 0,5%, now with 52 stales from 3700 shares I'm at about 1,4%
Is this normal?

Yes, unfortunately that's the downside of a mining proxy. With the extra hop in both directions, getworks and shares have greater age, and therefore have higher chance of arriving after a block change and being rejected. Multipool has longpolling to minimize stale shares, but even so it takes time for the pool to be notified of a block update and then notify the miners. Of course, all this takes place within an interval of a few seconds.

On the other hand, I occasionally see shares that are clearly within a block, have valid merkles and nonces, have a valid hash, and are not duplicates, but that nevertheless get rejected by the target pool, even as many other shares of similar age get accepted around the same time. Why does this happen? Couldn't really tell without knowing the internal workings of the other pools.

[superweb]

On the other hand, I occasionally see shares that are clearly within a block, have valid merkles and nonces, have a valid hash, and are not duplicates, but that nevertheless get rejected by the target pool, even as many other shares of similar age get accepted around the same time. Why does this happen? Couldn't really tell without knowing the internal workings of the other pools.

Is this happening on all pools? Btw the multipool's website is down for me, while the mining looks working fine.

[tschaboo]

On the other hand, I occasionally see shares that are clearly within a block, have valid merkles and nonces, have a valid hash, and are not duplicates, but that nevertheless get rejected by the target pool, even as many other shares of similar age get accepted around the same time. Why does this happen? Couldn't really tell without knowing the internal workings of the other pools.

It would be very interesting to see statistics about that happening: which pools are affected and how many percent of valid shares are rejected?

I noticed differences in stale-share percentage while trying all those pools but my hashing-power is rather low and the timeframe was too short to get statistically significance.

[shamen]

On the other hand, I occasionally see shares that are clearly within a block, have valid merkles and nonces, have a valid hash, and are not duplicates, but that nevertheless get rejected by the target pool, even as many other shares of similar age get accepted around the same time. Why does this happen? Couldn't really tell without knowing the internal workings of the other pools.

Related?

http://forum.bitcoin.org/index.php?topic=18567.msg277371#msg277371

http://forum.bitcoin.org/index.php?topic=14483.0

[Sukrim]

How hard is it to add new pools to this setup? There are multitudes of tiny proportional pools shooting up like mushrooms, waiting to be picked!

If you could abstract the info for pools in a config file, we might even be able to fill these out for you, so you just have to enter that information...

Only problem might be, that these pools then might feel like being DDOSed, if we have a certain hashpower already within multipool (which I think we do).

[burp]

The only problem might be that the extraction of the number of shares for the current round from each pool is different.

[Sukrim]

That's most likely "just a regex" or exposed via an API...

If not, then you'd have to guess/extrapolate from past performance I guess.