Bitcoin Forum
December 08, 2016, 06:24:39 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 [245] 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 ... 326 »
  Print  
Author Topic: [DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too  (Read 1453668 times)
DeepBit
Donator
Hero Member
*
Offline Offline

Activity: 532


We have cookies


View Profile WWW
April 17, 2012, 09:11:16 AM
 #4881

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.
Number of accounts won't make any difference. All shares are equal anyway.

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)
Measuring hashrate with your last 7 shares won't give any anything even remotely correct.
Set your averaging window to 30-40 minutes and you'll see better results.

Welcome to my bitcoin mining pool: https://deepbit.net ~ 3600 GH/s, Both payment schemes, instant payout, no invalid blocks !
Coming soon: ICBIT Trading platform
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481221479
Hero Member
*
Offline Offline

Posts: 1481221479

View Profile Personal Message (Offline)

Ignore
1481221479
Reply with quote  #2

1481221479
Report to moderator
1481221479
Hero Member
*
Offline Offline

Posts: 1481221479

View Profile Personal Message (Offline)

Ignore
1481221479
Reply with quote  #2

1481221479
Report to moderator
macbook-air
Sr. Member
****
Offline Offline

Activity: 322


View Profile WWW
April 17, 2012, 03:13:49 PM
 #4882

Hello, I am getting "Account_locked" while trying to create a new worker or change name of an existing worker. Why? I can still make manually payout.

DeepBit
Donator
Hero Member
*
Offline Offline

Activity: 532


We have cookies


View Profile WWW
April 17, 2012, 03:16:40 PM
 #4883

Hello, I am getting "Account_locked" while trying to create a new worker or change name of an existing worker. Why? I can still make manually payout.
Probably it was accidentally locked because of poolhopping. PM me your login name.

Welcome to my bitcoin mining pool: https://deepbit.net ~ 3600 GH/s, Both payment schemes, instant payout, no invalid blocks !
Coming soon: ICBIT Trading platform
BlackPrapor
Hero Member
*****
Offline Offline

Activity: 584



View Profile
April 18, 2012, 05:20:18 AM
 #4884

Number of accounts won't make any difference. All shares are equal anyway.
You're answering like a real politician  Grin

Measuring hashrate with your last 7 shares won't give any anything even remotely correct.
Set your averaging window to 30-40 minutes and you'll see better results.
I imagine my stated hash rate for each of the last 7 blocks should be somewhere around my real hash rate. I can setup averaging window to see my reported speed for the last X nimutes, but its still deviates alot in the last 7 blocks column. I point to this fact because I get paid based on those numbers. I guess it's just another variable which doesn't affect your income in the long run.

There is no place like 127.0.0.1
In blockchain we trust
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
April 18, 2012, 05:36:01 AM
 #4885

Number of accounts won't make any difference. All shares are equal anyway.
You're answering like a real politician  Grin
OK then: Your variance depends on total shares submitted. It doesn't matter if you submit them from one account or many.
Measuring hashrate with your last 7 shares won't give any anything even remotely correct.
Set your averaging window to 30-40 minutes and you'll see better results.
I imagine my stated hash rate for each of the last 7 blocks should be somewhere around my real hash rate. I can setup averaging window to see my reported speed for the last X nimutes, but its still deviates alot in the last 7 blocks column. I point to this fact because I get paid based on those numbers. I guess it's just another variable which doesn't affect your income in the long run.

Your round hashrate (in Mhps) is:

Code:
shares submitted for round * 2^32/10^6/time for round(in seconds)

Remember that the probability mass function (probabilities I gave above) is quite 'shallow' so variance is large. If the pool hashrate is stable, then your variance in round hashrate will be the same as your variance in shares submitted in a given round. For larger hashrates, the Poisson distribution variance is comparatively lower than for a low hashrate. So you're going to see significant variances in hashrate if you're looking at what the pool reports.

Asking about the variance of your shares submitted in a minute is the same as asking about the variance of your hashrate in a round.




Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
jkminkov
Hero Member
*****
Offline Offline

Activity: 534


View Profile
April 18, 2012, 07:09:16 AM
 #4886

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.

take a note, that some miners use 2 threads per GPU(cgminer by default), so your numbers need recalculation I think :]

Bleutrade
600 dollars in one place talking - Dudes, hooray, Bitcoin against us just one, but we are growing in numbers!
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
April 18, 2012, 07:52:22 AM
 #4887

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.

take a note, that some miners use 2 threads per GPU(cgminer by default), so your numbers need recalculation I think :]

No, for this analysis the way shares are created isn't important - only the total you send to the pool in a given period of time is. If you send more shares than your effective hashrate is higher.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 18, 2012, 10:40:10 AM
 #4888

And yet ... that is ignoring a few of the facts that do affect this:
Firstly there is a delay from when the pool gets a block until it informs each miner of that new block via an LP - and the 'miner' receives the LP
Secondly there is the delay from that LP to the time when the first share is expected to be found based on the mining power
Thirdly there is the delay in sending the share back to the pool

The miner will have an LP delay + expected time + reply delay that is either within the short block time or not ...

... and a VERY specific example would be a BFL mining device that will not return a share for LP delay + 5.x seconds + reply delay ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
April 18, 2012, 10:51:54 AM
 #4889

So how does that change if you have several accounts?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 18, 2012, 11:31:59 AM
 #4890

So how does that change if you have several accounts?
Well since the discussion started about getting shares in short rounds ...
and both you and DeepBit have stated that the number of accounts doesn't matter ...
My comments were pointing out that the hash rate is not the ONLY factor in determining if you will get shares in the short rounds.

However, now that you mention it, if you have more accounts, then you will have to receive more LP messages.
This will slow down the first item I listed above - such that the average time to get the LP for each account will increase since every account after the first one to receive the LP will of course receive it later.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
April 18, 2012, 11:38:58 AM
 #4891

So how does that change if you have several accounts?
Well since the discussion started about getting shares in short rounds ...
and both you and DeepBit have stated that the number of accounts doesn't matter ...
My comments were pointing out that the hash rate is not the ONLY factor in determining if you will get shares in the short rounds.
Quote
A miner can't do much about LPs. Just making sure BlackPrapor realises this.
However, now that you mention it, if you have more accounts, then you will have to receive more LP messages.
This will slow down the first item I listed above - such that the average time to get the LP for each account will increase since every account after the first one to receive the LP will of course receive it later.

Why is this? Workers on different accounts wont receive LPs sequentially afaik.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
DutchBrat
Hero Member
*****
Offline Offline

Activity: 868


View Profile
April 18, 2012, 11:42:18 AM
 #4892

Isn't the race to be the first to get the LP also a lottery like who get's to deliver the solution to the hash ?

i.e. If you have 100 rigs setup with 1 GPU you have 100 lottery tickets to be the first to get a LP as opposed to 20 rigs with 5 GPU's where you have only 20 tickets....

For the really short rounds (in the hundreds/few thousands of shares) your hashing power isn't so much what counts as it is the time in which you get the LP (and then of course deliver a solution before the round ends)
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 18, 2012, 12:08:31 PM
 #4893

So how does that change if you have several accounts?
Well since the discussion started about getting shares in short rounds ...
and both you and DeepBit have stated that the number of accounts doesn't matter ...
My comments were pointing out that the hash rate is not the ONLY factor in determining if you will get shares in the short rounds.
Quote
A miner can't do much about LPs. Just making sure BlackPrapor realises this.
However, now that you mention it, if you have more accounts, then you will have to receive more LP messages.
This will slow down the first item I listed above - such that the average time to get the LP for each account will increase since every account after the first one to receive the LP will of course receive it later.

Why is this? Workers on different accounts wont receive LPs sequentially afaik.
Unless I've completely missed something about non-broadcast TCP/IP packets travelling around the internet ...
... how can all the network packets arrive at the same time?

Even if the pool has multiple threads sending out the packets, they still have a sequential ordering through at least some the devices as they travel across the net - and of course the pool itself will not have as many threads as there are miners, that will be sending out the LP notices.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 18, 2012, 12:11:03 PM
 #4894

Isn't the race to be the first to get the LP also a lottery like who get's to deliver the solution to the hash ?

i.e. If you have 100 rigs setup with 1 GPU you have 100 lottery tickets to be the first to get a LP as opposed to 20 rigs with 5 GPU's where you have only 20 tickets....

For the really short rounds (in the hundreds/few thousands of shares) your hashing power isn't so much what counts as it is the time in which you get the LP (and then of course deliver a solution before the round ends)
Hmm what was the comment I made in IRC 9 hours ago to a pool OP ... Smiley

Quote
13:05 < kanoi> so ... ***** ... how does the pool decide the order it sends out LPs ...
(yes that is a rather controversial question, but only if the answer isn't truly random Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
April 18, 2012, 12:23:11 PM
 #4895

Isn't the race to be the first to get the LP also a lottery like who get's to deliver the solution to the hash ?

i.e. If you have 100 rigs setup with 1 GPU you have 100 lottery tickets to be the first to get a LP as opposed to 20 rigs with 5 GPU's where you have only 20 tickets....

For the really short rounds (in the hundreds/few thousands of shares) your hashing power isn't so much what counts as it is the time in which you get the LP (and then of course deliver a solution before the round ends)

That's pretty much the way I see it along with delays caused by geographical distance. I did some analysis here and found that I could model the LP response fairly well (although I wasn't sure it was due to LP at the time, I am now) . The response time was distributed as a log normal distribution, mean 0.7 seconds, sd 1.65 seconds.

So I think I see Kano's point now - LP variations will have an effect on your variance for very short rounds. If the model above holds, the mean lag time is about 7.5 seconds, median 2.01 seconds and a standard deviation of about 30. It's quite skewed, half of the miners getting LPs before 2 seconds, and the rest receiving the LPs from 2 seconds up to around 100 seconds after the start of the round.

Edit: This isn't taking into account the time for the share to get from the miner to the pool. Also, the mode is 0.13 seconds, so most miners will have received their LPs by then.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
April 18, 2012, 12:25:23 PM
 #4896

Why is this? Workers on different accounts wont receive LPs sequentially afaik.
Unless I've completely missed something about non-broadcast TCP/IP packets travelling around the internet ...
... how can all the network packets arrive at the same time?

Even if the pool has multiple threads sending out the packets, they still have a sequential ordering through at least some the devices as they travel across the net - and of course the pool itself will not have as many threads as there are miners, that will be sending out the LP notices.

Having more accounts doesn't mean you're going to increase the average time to get LPs, which is what I thought you were saying in the post. It just means a reduction in overall LP variance.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
April 18, 2012, 12:28:20 PM
 #4897

Isn't the race to be the first to get the LP also a lottery like who get's to deliver the solution to the hash ?

i.e. If you have 100 rigs setup with 1 GPU you have 100 lottery tickets to be the first to get a LP as opposed to 20 rigs with 5 GPU's where you have only 20 tickets....

For the really short rounds (in the hundreds/few thousands of shares) your hashing power isn't so much what counts as it is the time in which you get the LP (and then of course deliver a solution before the round ends)
Hmm what was the comment I made in IRC 9 hours ago to a pool OP ... Smiley

Quote
13:05 < kanoi> so ... ***** ... how does the pool decide the order it sends out LPs ...
(yes that is a rather controversial question, but only if the answer isn't truly random Smiley

I know that Slush prioritizes the LPs he sends out based on hashrate - I don't know whether Deepbit does this or not, but I think Slush is one of the only ones that does that.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
April 18, 2012, 12:32:33 PM
 #4898

I know that Slush prioritizes the LPs he sends out based on hashrate - I don't know whether Deepbit does this or not, but I think Slush is one of the only ones that does that.

Interesting. Prioritising by hashrate is probably a good way to reduce overall stales.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
P4man
Hero Member
*****
Offline Offline

Activity: 504



View Profile
April 18, 2012, 12:37:19 PM
 #4899

Bitminter does it too. Then again, with 100-150 GH there arent that many 1 minute rounds.

DutchBrat
Hero Member
*****
Offline Offline

Activity: 868


View Profile
April 18, 2012, 12:55:19 PM
 #4900

Isn't the race to be the first to get the LP also a lottery like who get's to deliver the solution to the hash ?

i.e. If you have 100 rigs setup with 1 GPU you have 100 lottery tickets to be the first to get a LP as opposed to 20 rigs with 5 GPU's where you have only 20 tickets....

For the really short rounds (in the hundreds/few thousands of shares) your hashing power isn't so much what counts as it is the time in which you get the LP (and then of course deliver a solution before the round ends)
Hmm what was the comment I made in IRC 9 hours ago to a pool OP ... Smiley

Quote
13:05 < kanoi> so ... ***** ... how does the pool decide the order it sends out LPs ...
(yes that is a rather controversial question, but only if the answer isn't truly random Smiley

I know that Slush prioritizes the LPs he sends out based on hashrate - I don't know whether Deepbit does this or not, but I think Slush is one of the only ones that does that.

So that effectively means that the higher your hash rate the more chance you have of submitting a share in a very short round.... so smaller miners will have less of a chance to participate in a 'more profitable' round than big miners. That means quick rounds don't even out based on variance... so the model becomes statistically biased as big miners will have  a bigger chance to begin with (of course you have to factor in geographics / network speed / etc etc)

Edit: Mind you, it is all mostly a hypothetical discussion as there aren't that many rounds where not all miners participate (on Deepbit) and even though it would be nice to get a 'huge' payoff in a round from time to time, I have the feeling that not participating in such a round won't affect your overall 'expected' payout that much....
Pages: « 1 ... 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 [245] 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 ... 326 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!