Topic: Multipool - the pool mining pool (with source code) - page 13. (Read 48269 times)

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).

Related?

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

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

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.

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

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.

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!

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 ?

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.

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.

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

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).

I cant seem to connect any more

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

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

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 know this doesn't answer your question, but I'm using multiple instances of miners for backup and for load balancing. Works well.

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!

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.

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

Cheers.

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.

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.

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.

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?

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.

Are you using shares+pending shares, or just shares? Mine are spot on using

earned = confirmed shares*Efficiency*50/877000, for 70000 confirmed shares

Trying for few days few with my one 6870