Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 326. (Read 837101 times)
February 03, 2012, 11:51:57 AM
I can't help but loathe the indaquate webforum threading...
February 03, 2012, 11:17:50 AM
I was referring to A1. I have full confidence in Dr H 
.
. February 03, 2012, 11:13:49 AM
Mind you, P4, the migration was a bit hasty... 
What if Doc opted to take the combat reconnaisance approach to pool server bugs?
What if Doc opted to take the combat reconnaisance approach to pool server bugs?
February 03, 2012, 11:10:06 AM
I would hope they have the sense to test their pool on the testnet first.
February 03, 2012, 11:02:10 AM
The worst thing about a new pool (or a pool after making any change) is that nagging voice saying "what is there is a bug, what if it is impossible to solve a block."
February 03, 2012, 10:54:03 AM
Whenever I try, I seem to get the glas-half-empty attitude. A voice keeps telling me "You've had your luck, partner. It's going to get a lot worse before it gets better"
uhmmm... wait, that's just my pet Raven... kindly disregard my bitching
What blows my mind it that it's A1's first block... what's the pool op doing? Sleeping? Should have killed it off like 2M shares ago.
Everyone should know when to fold and run to the hills, cut the losses.
uhmmm... wait, that's just my pet Raven... kindly disregard my bitching
What blows my mind it that it's A1's first block... what's the pool op doing? Sleeping? Should have killed it off like 2M shares ago.
Everyone should know when to fold and run to the hills, cut the losses.
February 03, 2012, 10:32:13 AM
Just use some twisted logic to make yourself believe its a good thing .
Here is how I do it: in the long run, we will not significantly deviate from the average. So all the bad luck we have now, will be compensated by yet to come luck. Some of the impatient will have left the pool by then, and therefore the patient one's will reap even more reward
. (please, dont bore me with statistics to prove me wrong!).
Seriously, a 5+M share block is gonna happen now and then. If its followed by a second "instant" block as we have seen a few times, suddenly it doesnt look so dramatic anymore.
Also, if it helps, A1bitcoinpool is still working on its first block, ~4.5M shares now. And its a proportional pool lol, so who in their right minds is going to mine there now? Have to feel sorry for the guys mining there.
.Here is how I do it: in the long run, we will not significantly deviate from the average. So all the bad luck we have now, will be compensated by yet to come luck. Some of the impatient will have left the pool by then, and therefore the patient one's will reap even more reward
. (please, dont bore me with statistics to prove me wrong!).Seriously, a 5+M share block is gonna happen now and then. If its followed by a second "instant" block as we have seen a few times, suddenly it doesnt look so dramatic anymore.
Also, if it helps, A1bitcoinpool is still working on its first block, ~4.5M shares now. And its a proportional pool lol, so who in their right minds is going to mine there now? Have to feel sorry for the guys mining there.
February 03, 2012, 10:04:30 AM
Someone shoot this damned block, please! ...or shoot me instead for I've had enough 
February 03, 2012, 02:29:45 AM
I threw some GPUMAX at you attempting to figure out what the use of leasing hashing power was. I'm still clueless. 
Well, it's very useful for me. I can see how much my server can handle, and find bottlenecks in my software.
I can see a few uses for it, but frankly none that would be enduring or explain all the >100% pps payout schemes propping up.
1) testing or kickstarting a pool. Has to be a small market, but completely legit and not that new (ie, no different than offering bonusses as many pools do in the early days).
2) poolhopping proportional pools, but apparently gpumax disallows that (no idea how they check that though)
3) malicious intent like a double spend attack. Although that would only be useful if you can attract a majority of the hashrate (possibly in combination with a DDoS attack to reduce overall hashrate) and even then you would only want to rent it for as long as needed to pull off the attack. Still this one scares me.
4) ponzi scheme, particularly those ones only paying out like once or twice a week.
Maybe I missed some, but whatever the use, most of these schemes do not tell you how your hashpower is used, some even clearly lie about it; I would refuse to rent my hashpower if I dont know how its used.
February 02, 2012, 05:42:40 PM
Now just so I understand how your payout system works, for shift #1398, my score is .01260124, meaning my reward will be around 50*.01260124, which is where my expected reward comes in. But this will only occur if the next block is found before shift #1408 ends, which will happen in about 6 hours or so. If no block is found by then, I'll get nothing.
Correct.
Quote
Question, suppose 2 blocks are found rapidly by your pool. A block is found in shift 1500 and shift 1501. The block in shift 1500 will be composed of the work done in shift 1490-1500. And then for the block in shift 1501 will be paid out to the workers in shifts 1491-1501, no?
Correct.
Just a heads up it is not possible to "game" PPLNS. If you do get paid for 2 blocks it would simply be luck not any mathematical advantage. If you get paid for none it once again is just bad luck. In the long run PPLNS ensures everyone is paid "fairly" because there is no method you can use to consistently gain a greater than average share (relative to hashing power provided).
February 02, 2012, 05:25:03 PM
Yeah, I'd love to see that option as well.
ABCPool's suspiciously high invalid rates always bothered me...
ABCPool's suspiciously high invalid rates always bothered me...
February 02, 2012, 05:11:36 PM
Dr. H not a high priority but could you consider seperating rejects into invalids & stales. I always assumed my cards were perfect but my backup pool is ABC Pool and I they break them out. I was surprised to see some invalid shares not just stale ones.
It would be useful for you too. Stales the pool is partially responsible for (prompt LP, fast getwork responses) but invalids are completely on the miner. There is nothing a "properly functioning" pool can do that would cause a miner to get invalids.
It would be useful for you too. Stales the pool is partially responsible for (prompt LP, fast getwork responses) but invalids are completely on the miner. There is nothing a "properly functioning" pool can do that would cause a miner to get invalids.
February 02, 2012, 05:07:09 PM
Well, it's very useful for me. I can see how much my server can handle, and find bottlenecks in my software.
Wonderful. Now just so I understand how your payout system works, for shift #1398, my score is .01260124, meaning my reward will be around 50*.01260124, which is where my expected reward comes in. But this will only occur if the next block is found before shift #1408 ends, which will happen in about 6 hours or so. If no block is found by then, I'll get nothing.
Question, suppose 2 blocks are found rapidly by your pool. A block is found in shift 1500 and shift 1501. The block in shift 1500 will be composed of the work done in shift 1490-1500. And then for the block in shift 1501 will be paid out to the workers in shifts 1491-1501, no? Is this how it works?
February 02, 2012, 04:59:27 PM
Add percentages beside the rejected numbers? Good idea. I put that on my list.
Yes, would be cool.
February 02, 2012, 04:34:02 PM
Well it's not too bad on my side. I'm down to 0.53% for this block. It looks like the FPGA have now a lower stale rate than the GPUs. Can you add the stale rate for each worker to the worker stats ? Would be interesting for tuning.
0.53% isn't very good. And somewhere around 160-170 GH/s stales suddenly rise a lot. Next update the back end should run much better.
Add percentages beside the rejected numbers? Good idea. I put that on my list.
I threw some GPUMAX at you attempting to figure out what the use of leasing hashing power was. I'm still clueless.
Well, it's very useful for me. I can see how much my server can handle, and find bottlenecks in my software.
February 02, 2012, 04:25:17 PM
Welcome to our new king of the hill
1 michaelmclees 33,117
33GH, thats some serious hashing power!
1 michaelmclees 33,117
33GH, thats some serious hashing power!
I threw some GPUMAX at you attempting to figure out what the use of leasing hashing power was. I'm still clueless.
February 02, 2012, 04:18:14 PM
Well it's not too bad on my side. I'm down to 0.53% for this block. It looks like the FPGA have now a lower stale rate than the GPUs. Can you add the stale rate for each worker to the worker stats ? Would be interesting for tuning.
February 02, 2012, 04:13:10 PM
Welcome to our new king of the hill
1 michaelmclees 33,117
33GH, thats some serious hashing power!
1 michaelmclees 33,117
33GH, thats some serious hashing power!
looks like he left early
He pushed up to almost 40 GH/s, then stales started rising.
What I found strange is that the new server isn't breaking a sweat, and still things slow down badly when the number of requests per second goes over a certain point. After watching the logs and numbers for a while I've located several bottlenecks in my programming. I hope to have a new version of the pool back end up sometime tomorrow. It should be able to make full use of the more powerful server.
sr. member
Activity: 266
Merit: 250
The king and the pawn go in the same box @ endgame
February 02, 2012, 03:34:17 PM
patience is a virtue
February 02, 2012, 03:27:11 PM
Meh. You get pissed off too easily. While bitminter server was having trouble, I temporarily moved to eclipse. My first full block there was 8M shares and in the next few blocks, there were 3 more 5-6+M share blocks without a single truly lucky one.
https://eclipsemc.com/block_stats.php (Ii started at their block 446).
https://eclipsemc.com/block_stats.php (Ii started at their block 446).
Jump to: