BitMinter.com * Optional Custom Miner, PPLNS, Merged mining, Newbie-Friendly! *

[nathanghart]

I hope this dosent mean the pool has somehow been deemed hoppable:

Rank    Name    Mhps
1   Fefox           84,345
2   bronan   79,607

..If not, then welcome.

They are not hopping, just making use of gpuMax to try and hit on some blocks. I'd like to thank them for trying to increase our pool luck with brute force and of course the extra bitcoins 

If the pool hits more frequently with this sort of artificial hash rate inflation, then it could attract more minters away from other pools permanently increasing our pool hash rate.

Of course, I am super new at this, so I could just be wrong about that. Anyway, thanks to FeFox and bronan for risking your bitcoins in hopes of landing the pool some coin.

[CrownCloud]

This miners GUI looks pretty cool, I've used it on my old GFX card, worked well can you support it to run on other pools aswell ?

[DrHaribo]

This miners GUI looks pretty cool, I've used it on my old GFX card, worked well can you support it to run on other pools aswell ?

Glad you like it Supporting other pools is on the list, but I'm not sure when I get around to it. People keep giving me so many great ideas that the TODO list by now is probably several years long. Multi pool support is not at the bottom of that list, though, but I do have some more important things to do first.

I hope this dosent mean the pool has somehow been deemed hoppable:

Rank    Name    Mhps
1   Fefox           84,345
2   bronan   79,607

..If not, then welcome.

As was already said it's GPUmax. It's very nice that people run some GPUmax hashes in the pool. Just be aware that you have to pay more for those hashes than their expected value. That means there's a smaller chance of making a profit, than ending up with a loss. It's a bit like gambling in a casino. It can be fun, but don't expect to still have your money when you leave.

When GPUmax gets a little bigger maybe I can rent 1000 GH/s for a while to see how it affects the server load. When the pool was doing 320 GH/s I could barely see any load. Gotta love the new server!

[P4man]

When GPUmax gets a little bigger maybe I can rent 1000 GH/s for a while to see how it affects the server load. When the pool was doing 320 GH/s I could barely see any load. Gotta love the new server!

You will have to upgrade your "speed dials" though, it was maxed out at 300 :p

[DrHaribo]

You will have to upgrade your "speed dials" though, it was maxed out at 300 :p

Hmm, yeah. But if I set the max to the true max for the new server, the current speed will look so puny. Guess I need to make it dynamic.

[P4man]

When GPUmax gets a little bigger maybe I can rent 1000 GH/s for a while to see how it affects the server load. When the pool was doing 320 GH/s I could barely see any load. Gotta love the new server!

Rejection rate with GPUmax still seems a problem though. I briefly saw 18% on the current shift. Ouch. Im assuming its gpumax related since I had 0.0%

[DrHaribo]

Rejection rate with GPUmax still seems a problem though. I briefly saw 18% on the current shift. Ouch. Im assuming its gpumax related since I had 0.0%

Yeah, it's because of how they do long polling. I guess they get 1% to 2% stales or so.

Stales come at the block change, in a pile. If there is a new shift just starting at the time of the block change, then the new shift will contain a lot of stales in the beginning. After a few minutes the stale percentage should look much better again.

I'm considering whether I should disable extrapolation of stales. It is probably more accurate to only use actual stale numbers and not update them before a new number is received from the server. Not only does it look strange the stales slowly creeping up even without block changes, but the extrapolation often seems very inaccurate too.

[chriswr]

What happens when CDF gets to 100% - will the world end ?

Can CDF ever get to 100% or will it just stick at 99.99% 

[DeathAndTaxes]

Can CDF ever get to 100% or will it just stick at 99.99%  

99.9%, 99.99%, 99.999%, 99.999999999999999999999999999999999999999999999999999999999999999999%

To understand CDF. Imagine you flipped a coin and when it was heads you win.

Say you flipped 3 tails in a row.  The chance of the next flip hasn't changed (50/50) but you can say the odds of having that bad of luck are (0.5*0.5*0.5)= 0.125.  The reverse of that is that 87.5% of the time you will not have luck this bad.  Your CDF is 87.5% of the sequence of events so far.

Say on another run you flipped 20 tails (losses) in a row.  Your CDF would be 99.9999046%
In reverse you could look at that and say the odds I will have luck that bad again are 0.0000954%.

Key thing to remember is that CDF is only backwards looking.  The chance of the next flip is still 50/50.

CDF for Bitcoin works the same way except you "lose" on a worthless hash and you "win" on a block solving hash.  Instead of 50/50 the odds of winning on each hash is much smaller.  (2^32)*(1.37 million) ~= 1 in 5.8x10^15.  Note the second number is difficulty which currently is roughly 1.37 million.

[chriswr]

We should run a book on what it will get to ?
I bet 99.92 % 

[chriswr]

Hmm, understand the coin flip 50 : 50 bit but not sure  I get how it works with bitcoins.-

With the odds of winning on each hash is much smaller than 50:50 ,
when you multiply them together, how come the CDF does go to 95%+ at the start ?

[chriswr]

how come the CDF does NOT go to 95%+ at the start ?

[DeathAndTaxes]

how come the CDF does NOT go to 95%+ at the start ?

CDF shows the statistical odds that you would have solved a block "by now".

So at the start of the round after 1 share the CDF is 0.0000730%.  The CDF is saying only roughly 1 in 1.37 million blocks are solved this quickly.

On average we will solve one block every (difficulty) shares.  Currently that is ~1.37 million.  So at 1.37 million shares CDF will be 50%.   Roughly half the blocks (difficulty adjusted) have been solved faster and half long.

Our CDF currently is 98.95% thus with this many shares produced 98.95% of the time would have solved a block by now.  98.95% of blocks are solved with less shares and 1.05% of blocks are solved in longer number of shares (difficulty adjusted).

[ZodiacDragon84]

As it stands, this block must end eventually. (let us hope sooner, than later)

[DrHaribo]

Version 1.1.1 beta of the BitMinter client is ready for testing:

https://bitcointalk.org/index.php?topic=31163.msg758061#msg758061

Could someone with a 7970 see if it runs ok?

P.S. Please end this block!

[chriswr]

how come the CDF does NOT go to 95%+ at the start ?



CDF shows the statistical odds that you would have solved a block "by now".

So at the start of the round after 1 share the CDF is 0.0000730%.  The CDF is saying only roughly 1 in 1.37 million blocks are solved this quickly.

On average we will solve one block every (difficulty) shares.  Currently that is ~1.37 million.  So at 1.37 million shares CDF will be 50%.   Roughly half the blocks (difficulty adjusted) have been solved faster and half long.

Our CDF currently is 98.95% thus with this many shares produced 98.95% of the time would have solved a block by now.  98.95% of blocks are solved with less shares and 1.05% of blocks are solved in longer number of shares (difficulty adjusted).

Yes - Thanks, got it now.

But one more CDF question for you, How can the current CDF go down ? - last night it was 99.7% (23:30 GMT) , this morning it was down to 96.6% (08:30 GMT),- Now it's back to 99.07%
What's going on ?

[DrHaribo]

But one more CDF question for you, How can the current CDF go down ? - last night it was 99.7% (23:30 GMT) , this morning it was down to 96.6% (08:30 GMT),- Now it's back to 99.07%
What's going on ?

CDF only goes down when a block is built. When that happens it should go back to zero.

I believe those first 2 numbers were the NMC CDF. That was the bug I fixed today. When we built a namecoin block this morning the CDF should have gone back to zero. Proofs of work should also have gone to zero. And the round duration should have gone back to zero seconds. But because of the bug the NMC round stats only partially reset. That's why the CDF only dropped a little.

A new version of the backend is running now, and round statistics should be resetting properly again when a new block is generated.

[DeathAndTaxes]

how come the CDF does NOT go to 95%+ at the start ?



CDF shows the statistical odds that you would have solved a block "by now".

So at the start of the round after 1 share the CDF is 0.0000730%.  The CDF is saying only roughly 1 in 1.37 million blocks are solved this quickly.

On average we will solve one block every (difficulty) shares.  Currently that is ~1.37 million.  So at 1.37 million shares CDF will be 50%.   Roughly half the blocks (difficulty adjusted) have been solved faster and half long.

Our CDF currently is 98.95% thus with this many shares produced 98.95% of the time would have solved a block by now.  98.95% of blocks are solved with less shares and 1.05% of blocks are solved in longer number of shares (difficulty adjusted).

Yes - Thanks, got it now.

But one more CDF question for you, How can the current CDF go down ? - last night it was 99.7% (23:30 GMT) , this morning it was down to 96.6% (08:30 GMT),- Now it's back to 99.07%
What's going on ?

It can't.  If it did and you were looking at the same block (BTC and NMC have their own CDF) then it must be a "glitch".  Maybe Dr H knows more.

[chriswr]

It can't.  If it did and you were looking at the same block (BTC and NMC have their own CDF) then it must be a "glitch".  Maybe Dr H knows more.

hmm - Am sure I was looking at the BTC block - maybe someone else can remember ? 

[DrHaribo]

hmm - Am sure I was looking at the BTC block - maybe someone else can remember ? 

Hm, perhaps it could be the extrapolation. The round stats update on the page every 2 minutes. The changes in between that are extrapolated based on current hash rate.

If someone runs GPUmax and pushes the hash rate up, then later the hash rate drops suddenly when the GPUmax run is over. The extrapolation will keep showing everything moving at the same rate until the next real data comes, which could be 2 minutes later. At that point all the numbers are corrected.

For the same reason you can also sometimes see that you go from X to X+1 rejected proofs of work, then suddenly back to X.

I'm thinking of turning off extrapolation for rejects. They don't come at a steady pace anyway, just at the block changes. I'm also thinking of reducing the updates to every minute.

Hm, not sure if 2 minutes of wrong extrapolation can explain a change as big as the one you mentioned, but it's the only thing I can think of.