Pages:
Author

Topic: [DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too - page 83. (Read 1601330 times)

hero member
Activity: 628
Merit: 504
BlackPrapor you requested someone work out the variance you can expect for you? I'll go one better.

If you have a 6970, I'm guessing you have a hashrate of 350 Mhps? Then you're submitting on average 4.88 difficulty 1 shares per minute. At the current pool hashrate of 3500Ghps, 50000 shares will take 61 seconds. Since the number of shares you submit in a given time is a poisson distributed variable, both the mean and the variance of your submissions in 61 seconds = 4.97. Let's round that to 5.

That might not be helpful, but below is a table of probabilities that you will submit a given number of shares in 61 seconds:
Code:
Shares     Probability  
0          0.006737947
1          0.033689735
2          0.084224337
3          0.140373896
4          0.175467370
5          0.175467370
6          0.146222808
7          0.104444863
8          0.065278039
9          0.036265577
10         0.018132789

At current difficulty  the probability of a round lasting 25000 to 75000 shares is about 0.03. At the current pool hashrate, a block will be solved on average every 32 minutes, or 315 rounds per week. So in a week you'd see 10 rounds between 25000 and 75000 shares.

So you see it's not unlikely, but certainly not usual, that in a week there would be a 50000 share round in which you'd submit no shares.

Thanks a lot for the info. As you can see here, my chances of getting 0 shares for small blocks are around 0.6%. I've been mining here for around 17 days, and got a few 0 share bloks already  Roll Eyes...which makes me think I'm special  Grin.
I wasn't implying that you can get higher profits. If you read carefully, all I was after is reduced variance. Both variances. Deepbit, you're saying that you have to be lucky to get a share in a small block and in time it averages out anyway. All I'm asking is whether I'll be able to reduce variance by having many accounts, and getting a share in a small block at least with some of those accounts. Since this topic already been discussed earlier, I wont bugger you guys with these questions anymore =) Thanks.

P.S. BTW, I'm using proportional payouts and my hash speed for the last 7 shares reported on account page is quite weird. I get anything from 190Mhs up to 933Mhs per round. My card's speed is stable though, at 362,8Mhs (not overclocked)
donator
Activity: 532
Merit: 501
We have cookies
Well, Deepbit is saying that when it comes to submitting a share for a small block, it doesn't matter what's your hash rate, it's totally depends on whever you will be one of those who receive getwork for that block. So, that means it depends on your proportion of the "number" of pool users.
I think deepbit is mostly wrong. You have to get the getwork of course, but in a round that takes 1 minute, you should get it.
Initially I was talking about the chance of getting a share in that 29-shares round, which depends not only on mining luck, as usual, but also on the LP reaction delay/luck because it lasted just a fraction of a second.
(EDIT: No, the 29-shares-round discussion was on the previous page)

But this doesn't affects anything too. About 200 pages ago this question was already answered many times: not getting a share in short block won't affect your average reward because sometimes you WILL get a share in similar conditions and it will average out.

So you're saying that it more depends (or completely depends) on the number of pool users, and not their hash rate?
P.S. Would I be able to reduce variance on luck for small blocks if I have 50 accounts with smaller hash speed, instead of 1 fast?
No, accounts number won't make any difference. I just mean that there are LOTS of miners who submitted a share in that block, but THIS time you weren't among them.
If there were any troubles with short blocks then we would notice considerable hashrate drops at those moments.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
BlackPrapor you requested someone work out the variance you can expect for you? I'll go one better.

If you have a 6970, I'm guessing you have a hashrate of 350 Mhps? Then you're submitting on average 4.88 difficulty 1 shares per minute. At the current pool hashrate of 3500Ghps, 50000 shares will take 61 seconds. Since the number of shares you submit in a given time is a poisson distributed variable, both the mean and the variance of your submissions in 61 seconds = 4.97. Let's round that to 5.

That might not be helpful, but below is a table of probabilities that you will submit a given number of shares in 61 seconds:
Code:
Shares     Probability 
0          0.006737947
1          0.033689735
2          0.084224337
3          0.140373896
4          0.175467370
5          0.175467370
6          0.146222808
7          0.104444863
8          0.065278039
9          0.036265577
10         0.018132789

At current difficulty  the probability of a round lasting 25000 to 75000 shares is about 0.03. At the current pool hashrate, a block will be solved on average every 32 minutes, or 315 rounds per week. So in a week you'd see 10 rounds between 25000 and 75000 shares.

So you see it's not unlikely, but certainly not usual, that in a week there would be a 50000 share round in which you'd submit no shares.
hero member
Activity: 518
Merit: 500
Yes, I think it's possible to have both with certain hash rate and a proportion of the pool you're in (or solo, as you mentioned). That's why large scale mining farms would be more profitable

Not true. It doesnt matter. Think of it this way, with your one card, granted,  you may miss some small blocks, but OTOH its also possibly you will get 5x more than average on that short block. heck, theoretically you could make 50BTC on a single share block. The larger the hashrate, the more improbable such luck becomes (per MH!), just as the more improbable bad luck becomes. But good and bad luck even out, really, there is no difference  in revenue per MH for small miners or huge farms. For every short block you got unlucky on, there will be one where you got lucky.

If you want to improve your revenue per MH, simply go mine somewhere where fees are lower. That really does make a difference Smiley.
hero member
Activity: 628
Merit: 504
Well, Deepbit is saying that when it comes to submitting a share for a small block, it doesn't matter what's your hash rate, it's totally depends on whever you will be one of those who receive getwork for that block. So, that means it depends on your proportion of the "number" of pool users. Then it seems logical that when only a small number of pool users get that work, the larger your user account number, the more your chances of getting that work are. What do you think?

I think deepbit is mostly wrong. You have to get the getwork of course, but in a round that takes 1 minute, you should get it. Processing and submitting a valid share based on it within 1 minute is something else entirely, and the higher your hashrate, obviously, the better your odds. So hashrate does matter.  

What I think he means, is that for overall profits it doesnt matter, and then he is right. Higher hashrate will mean (slightly) lower variability, but your overall expected revenue per MH is the same. Its just like mining solo, the bigger your hashrate, the lower the variance, but it has no impact on your expected overall btc/MH.


The good thing is, that in due time I would be able to do an experiment with 50 miners and see who's right. I could setup 50 accounts, and then merge them into 1 and see which one option gives me more chances with getting shares in small blocks. Untill then I guess it doesn't matter what we think about this =)

P.S. P4Man, I think you're right about the number of accounts relevance to the luck variance. If the work is distributed among the workers as per thread, not user account, then it doesn't really matter how many accounts you have, it matters how many threads your workers have in total and their total hash rate.
hero member
Activity: 628
Merit: 504
I get what you're saying. I know that. You're confusing block luck variance and getting a share in a small block variance.

No, Im not. But you can only decrease one at the expense of the other with a given hashrate.

To look at the extreme ends of the spectrum, you can eliminate the "share per small block variance" completely only by mining solo, then you will always have 100%. You can eliminate the the block length variance only by going PPS. You can can have almost anything inbetween, but you cant have both. Deepbit prop is as close to PPS as you will get on a proportional payout scheme, its therefore logical the per share in short block variance is as high as it gets, because your % of the overall hashrate is minimal.  Deepbit will sometimes find blocks in the time it takes you to find a single share. There is no way around that. That can work out both ways though, as either very lucky or unlucky.

Yes, I think it's possible to have both with certain hash rate and a proportion of the pool you're in (or solo, as you mentioned). That's why large scale mining farms would be more profitable (I think Vladimir already knows that  Grin). But it's still should be possible to find a certain pool size and number of users for your hash rate, where you get low variance of both "lucks", maybe even close to 0% chance of not getting small block share.
hero member
Activity: 518
Merit: 500
Well, Deepbit is saying that when it comes to submitting a share for a small block, it doesn't matter what's your hash rate, it's totally depends on whever you will be one of those who receive getwork for that block. So, that means it depends on your proportion of the "number" of pool users. Then it seems logical that when only a small number of pool users get that work, the larger your user account number, the more your chances of getting that work are. What do you think?

I think deepbit is mostly wrong. You have to get the getwork of course, but in a round that takes 1 minute, you should get it. Processing and submitting a valid share based on it within 1 minute is something else entirely, and the higher your hashrate, obviously, the better your odds. So hashrate does matter. 

What I think he means, is that for overall profits it doesnt matter, and then he is right. Higher hashrate will mean (slightly) lower variability, but your overall expected revenue per MH is the same. Its just like mining solo, the bigger your hashrate, the lower the variance, but it has no impact on your expected overall btc/MH.
hero member
Activity: 628
Merit: 504
Quote
P.S. Would I be able to reduce variance on luck for small blocks if I have 50 accounts with smaller hash speed, instead of 1 fast?

No. Join a smaller pool where your % is larger. That will decrease the variability of your % on short blocks, but of course your overall variability will only increase because a smaller pool has a bigger per day or per week variability. 

Well, Deepbit is saying that when it comes to submitting a share for a small block, it doesn't matter what's your hash rate, it's totally depends on whever you will be one of those who receive getwork for that block. So, that means it depends on your proportion of the "number" of pool users. Then it seems logical that when only a small number of pool users get that work, the larger your user account number, the more your chances of getting that work are. What do you think?
hero member
Activity: 518
Merit: 500
I get what you're saying. I know that. You're confusing block luck variance and getting a share in a small block variance.

No, Im not. But you can only decrease one at the expense of the other with a given hashrate.

To look at the extreme ends of the spectrum, you can eliminate the "share per small block variance" completely only by mining solo, then you will always have 100%. You can eliminate the the block length variance only by going PPS. You can can have almost anything inbetween, but you cant have both. Deepbit prop is as close to PPS as you will get on a proportional payout scheme, its therefore logical the per share in short block variance is as high as it gets, because your % of the overall hashrate is minimal.  Deepbit will sometimes find blocks in the time it takes you to find a single share. There is no way around that. That can work out both ways though, as either very lucky or unlucky.
hero member
Activity: 628
Merit: 504
So you're saying that it more depends (or completely depends) on the number of pool users, and not their hash rate?

It depends entirely on your share of the pools hash rate, so

Quote
P.S. Would I be able to reduce variance on luck for small blocks if I have 50 accounts with smaller hash speed, instead of 1 fast?

No. Join a smaller pool where your % is larger. That will decrease the variability of your % on short blocks, but of course your overall variability will only increase because a smaller pool has a bigger per day or per week variability.  


I get what you're saying. I know that. Ceteris paribus, in a small pool you have larger block luck variance, but smaller small block luck variance (if you get what I mean), but only if your luck for small blocks really depends on your proportion of the total pool speed (not the number of users, as DeepBit suggests). My theory is, that there should be a certain pool speed for your farm to produce with less total variance (that is total block size variance + small block variance where you have a chance of not getting a share at all), which depends on a weighted average of two variables. That is your proportion of the pool's speed and your proportion on the pool's number of users.

P.S. I have no idea what's the weight of each variable though.
hero member
Activity: 518
Merit: 500
So you're saying that it more depends (or completely depends) on the number of pool users, and not their hash rate?

It depends entirely on your share of the pools hash rate, so

Quote
P.S. Would I be able to reduce variance on luck for small blocks if I have 50 accounts with smaller hash speed, instead of 1 fast?

No. Join a smaller pool where your % is larger. That will decrease the variability of your % on short blocks, but of course your overall variability will only increase because a smaller pool has a bigger per day or per week variability. 
hero member
Activity: 628
Merit: 504
That info should give some idea on your minimum required proportion of pool's hash rate so you don't get any blocks with 0 shares. I imagine it would be hard to get that proportion in such a large pool as DeepBit, which makes me think that there should be a "golden middle" of the pool size for your specific hash rate. In case I can get all the data required to calculate that formula, I'll try.
If you are getting LP correctly, you'll always have chance to submit a share in ANY block.
Actually even without LP you still have your chance. If you see a round with 50 000 shares, it means that at least hundreds or users managed to submit, may be even thousands, and I doubt that they are all in multi-GH/s range.

Also you can get 0 shares too, even with high hashrate.

So you're saying that it more depends (or completely depends) on the number of pool users, and not their hash rate?

P.S. Would I be able to reduce variance on luck for small blocks if I have 50 accounts with smaller hash speed, instead of 1 fast?
hero member
Activity: 518
Merit: 500
I've noticed that with my 1 HD6970 I do get 0 shares for some blocks that are less than 50000 shares in size. That makes me think that finding too small blocks will raise variance in payouts.

Obviously it will, and its completely logical. The sheer existence of short and long blocks already is what causes variance, and being able to get proportionally more or less shares in to short rounds exacerbates that.

Deepbit has 3.5 GH. A 50K share round takes about 1 minute.  With a single 6970 you get what, 4-5 shares per minute on average? No surprise on some blocks you wont hit any. But on others you might get lucky and get 10 or more shares in. It should average out.

If you dont like variance, go to a PPS pool.
donator
Activity: 532
Merit: 501
We have cookies
That info should give some idea on your minimum required proportion of pool's hash rate so you don't get any blocks with 0 shares. I imagine it would be hard to get that proportion in such a large pool as DeepBit, which makes me think that there should be a "golden middle" of the pool size for your specific hash rate. In case I can get all the data required to calculate that formula, I'll try.
If you are getting LP correctly, you'll always have chance to submit a share in ANY block.
Actually even without LP you still have your chance. If you see a round with 50 000 shares, it means that at least hundreds or users managed to submit, may be even thousands, and I doubt that they are all in multi-GH/s range.

Also you can get 0 shares too, even with high hashrate.
hero member
Activity: 628
Merit: 504
That sounds correct for the short 29 share round but I would of at least expected a few hundred shares out of the 96659 round. The fact that I didn't even get 1 with 11 gh/s is what seems wrong.
You should get more than 260 shares from 96659-shares round. But this also may depend on your miner, your hardware (if you using something non-standard) and your luck.
This round was 2-minutes long, so if you don't get even a single share this may mean that something may be wrong with your miner. May be it was switched to your backup pool for some reason ?

Did you get any shares from 5868-long round ?

I've noticed that with my 1 HD6970 I do get 0 shares for some blocks that are less than 50000 shares in size. That makes me think that finding too small blocks will raise variance in payouts. Could someone with mathlab or some software like it calculate the distribution of payouts variance relative to the block size found? I.e. how strong is the variance at each size of the block. At least one month of blocks history is preferrable to use. Maybe if we had data of current pool speed for each block found, we could calculate how much that variance depends on the pool's speed. That info should give some idea on your minimum required proportion of pool's hash rate so you don't get any blocks with 0 shares. I imagine it would be hard to get that proportion in such a large pool as DeepBit, which makes me think that there should be a "golden middle" of the pool size for your specific hash rate. In case I can get all the data required to calculate that formula, I'll try.
member
Activity: 87
Merit: 10
That sounds correct for the short 29 share round but I would of at least expected a few hundred shares out of the 96659 round. The fact that I didn't even get 1 with 11 gh/s is what seems wrong.
You should get more than 260 shares from 96659-shares round. But this also may depend on your miner, your hardware (if you using something non-standard) and your luck.
This round was 2-minutes long, so if you don't get even a single share this may mean that something may be wrong with your miner. May be it was switched to your backup pool for some reason ?

Did you get any shares from 5868-long round ?

I have 8 rigs directed to you.I don't have any back up pool set up right now. I got 29 shares out of the 5868 long round. I'm on site with the rigs and all before and after rounds are correct.

hero member
Activity: 518
Merit: 500
The difficulty history below that is also either completely fubar, or I dont understand what its showing.
It shows average shares per block during that difficulty period.

Ah. That explains the percentages. But I guess its completely logical its ordered descending by difficulty so we see 10 month old data first Smiley
donator
Activity: 532
Merit: 501
We have cookies
The difficulty history below that is also either completely fubar, or I dont understand what its showing.
It shows average shares per block during that difficulty period.
hero member
Activity: 518
Merit: 500
Since you are fixing minor bugs on that page; when you click a date in the 'stats by date', you get the results for the day preceding the day you clicked.

The difficulty history below that is also either completely fubar, or I dont understand what its showing.
hero member
Activity: 533
Merit: 500
I also appreciate seeing the displayed times for each block.  I know the timestamps are correct but it's so much nicer just seeing how long it took displayed rather than figuring it out.  Thanks for fixing or re-enabling it.
Pages:
Jump to: