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

I only solo mined 24 shares out of 2400

so it's like hitting continuum with 500mh/s :/

Because that would get you banned on that pool for DOSing.

I don't have stats for Multipool, but I guess since it can be more efficient than others and is really easy to set up I expect it to be in the 50 GH/s range.

Now imagine hitting a smaller, but fair pool like Continuum every once in a while with THAT.

no, what I'm saying it should charge a fee based on the total additional bitcoins
charge that fee every time the person cashes out

my earned is right now 0.06851642 and I paid 0.00136617 in fees which is a total of 2% overall and my efficiency is 1.148 so that means I'm paying 1/7 of my supposed profit to the pool itself

Also: instead of solo, why not join a pool that cannot be exploited, but just to give the miner a fair share?

I can see you're having a lot of fun with this. I like it!

BTW, I just got my first payout.

Finished a major overhaul of the getwork module to combat all the outages the pool has been experiencing. Getworks are now completely de-threaded and parallelized: the queue gets filled continuously by all the pools, in order of preference (no getworks are wasted, but more are obtained from higher-preference pools whenever possible). The quality-of-service checks have been changed accordingly so that Multipool should no longer manage to ban all the pools it mines from for insufficient responsiveness. As a final fallback, the pool now generates its own work a-la solo mining. Haven't yet decided which reward system to use for the solo shares .

All this effort to manage workloads has unfortunately detracted me from the more profitable pool additions - more pool scrapping. As it is, Multipool is being squeezed tight by being forced to avoid zealous automatic DoS defenses, and is really only mining at full strength from half of the pools in the current rotation. More pools in rotation will certainly help things move along. Efficiency has been somewhat lacking lately in comparison to what could be achieved.
Continuum pool would definitely be a great addition!

That's even too devious for my tastes  . I suspect though that the window of opportunity is narrower than one might think. The shares go stale pretty quickly, I wouldn't want to hold on to one for longer than a minute.

No, you are right. The reason is that Multipool has been constrained by the rate of getwork requests it can wrest from the pools. At times, some of the pools are under a lot of load and have latencies above 0.5s, ten times the normal rate. With the new parallelized getwork module, the pool should now be able to grab all the shares possible.

As for the fees, honestly, they should really be calculated based off the total efficiency, not for individual rounds. I don't want to just skim off natural variance. The difficulty with that was that since total efficiency varies, the total collected fee could go up or down at any time, and I didn't want to deal with that. Once I have the time, I'll whip up a better fee calculator.

Yeah, I also understand it like that. If we'd get a negative fee for <0% efficiency shares, that could ruin Multipool if the pool hopping no longer works. He/She could change it to a combined fee when paying out, depending on the efficiency since the last payout. That fee would probably be higher than 5%.

After all, I'm not so sure that mining at multipool actually results in a higher payout than simply mining at a standard pool. (But pool hopping does work.)

yeah but the next couple of blocks have 39 efficiency (probably getting rewarded for earlier blocks), and I'm getting charged a fee on them, while the ones that have "0" I don't get my fee back
so in this way I'm getting overcharged since the fee is per sequence of blocks, NOT on the total

I have 1.4 efficiency, but I'm not getting charged 5% fee on the 40%, I'm getting charged 5% fee on like the 80% of blocks and the ones that have 60% (or even 0%) efficiency don't give the fee back
am I misunderstanding this or is this the case?

Explained here:

http://forum.bitcoin.org/index.php?topic=17970.msg240413#msg240413

How did I get 0 from BTCMine?

132026   Mon Jun 20 09:00:12 2011   136   124.482   0.00000000   0.000   0.00000000

is it possible to receive exactly 0?

Of course you can. Their stats will be combined then though.

im curious. youuc an point multiple miners using the same bitcoin waller address?

As far as I understood it, you could get 1.28 on each pool - so in 2 pools it should be even higher...

It went up to 106.7% for me btw. - seems to still fluctuate quite a bit  even with this sample size


Also looking forward to the next payment! *cough*

From what I understood of Raulo's paper (and please correct me if I'm wrong) but efficiency should tend toward 1.28 for proportional pools. I'm not sure how score based pools affect this, since both slush and eligius have decay and eligius is on 2.5 for me, but slush only 0.9. But at a guess, the long term efficiency shouldn't be too different from 1.28.

Anyway:

Shares (pending)   39760
Utility   42376.960
Earned   2.32727847
Efficiency   1.233
Collected   1.79975253
Paid   0.65212834

Last pay was two days ago. So I'm looking forward to that next pay Multipool.....

Shares   367
Shares (pending)   1774
Utility   618.643
Earned   0.05420515
Efficiency   2.590
I have fairly high hopes

oh, way way less I only mined for a day and most of these are not confirmed so apparently I run good

I sent some shares to eligius and it was really low efficiency so I'm down to 1.388

i got 5600 confirmed shares and stay way lower then 1.77. I wonder how someone would have got 1.77. I assume, saturday was a bad day because there where just 2 pools involved. But 1.77 sounds high. I am right that all user Switch pools at the same time (after finished their last share on one pool)?

Moreover there where more downtimes and the risk about multipool get banned from other poos and the pending shares a lost. For this, i cant see any real win yet, letz see what happens the next 24 hours.

Greetings
Mike

I've been testing this pool for some time now and wondering how it figures out which pool to use for getting work.

As it seems, eligius-eu has found a block about 30 minutes ago, so it should be quite profitable to mine there now. However my stats page shows that so far only 28 of my shares have been submitted to eligius-eu in their current round, while I did probably mine ~100 shares total in 30 minutes. It is to my surprise that 5 shares have been sent to BTC Guild, even though they are on a 2:20h round, and 67 to btcmine with a score-based reward, giving only 60 utility for those 67 shares (while the 28 eligius shares are 72 utility).  (I just noticed that these 3 numbers sum up to 100 indeed, while my original 100 was just an estimate based on my hashrate. hah! )

If I attempted to write a pool hopping software, I'd guess that this is a bug in my code. Or why should the majority of shares go to a score based pool when I am certain that eligius has found a block just a few minutes ago and is probably well below 43% of difficulty? Maybe it's because eligius can't answer getwork requests fast enough?

Update: Sure enough, that eligius-eu round ended 40 mins after it started, giving a 4.498 efficiency. I only had 36 shares sent into that eligius round, while in the same time span I sent 98 to btcmine. I'm not sure that this works as good as it is supposed to. Or am I getting it totally wrong?

With how many shares?

I have ~18000 shares confirmed and an efficiency of 1.054

Unfortunately I cannot say if this is really true/good because of a few downtime-hiccups, so I canont say how long exactly I mined in the past 24 hours with which hash rate to give a really precise answer if this is above or below expected values

you run bad, mine is 1.77

due to the downtime I've only been able to send around 820Mh/s toward multipool.
For what it's worth, I predict it'll be more profitable than sticking to a single mining pool. My utility is 167 + my efficiency is just over 1