but you know how we like changing things?
Ozcoin is 0fee on DGM till next Sunday - as a small way to compensate for recent downtime
PPS will remain at 4%
Cheers
Graet
Topic: Weekly pool and network statistics - page 23. (Read 91451 times)
cheers ooc
but you know how we like changing things?
Ozcoin is 0fee on DGM till next Sunday - as a small way to compensate for recent downtime
PPS will remain at 4%
Cheers
Graet
but you know how we like changing things?
Ozcoin is 0fee on DGM till next Sunday - as a small way to compensate for recent downtime
PPS will remain at 4%
Cheers
Graet
14th October weekly pool statistics
I hope everyone got some use out of the Variable pool difficulty post. If anything's not clear, please post a comment or contact me with your questions.
Most pools lost some percentage of the network hashrate this week - BTCGuild and Bitminter were the only pools to experience a continuation of hashrate increase.
If there's significant (successful) pool hopping going on at Deepbit it's being hidden by the general variation in pool hashrate there at the moment. Pool hopping at slush's pool has reduced significantly.
There is something odd happening with my calculations of BTCGuild's luck - the shares per round I'm estimating is far too high. I'll try to figure out how to fix it this week.
Two unexpectedly large donations over the last fortnight - thank you very much to my mysterious benefactors! Smaller donations are just as welcome though: 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
You can view all charts at http://organofcorti.blogspot.com
6th October weekly pool statistics
Well, it seems that Deepbit has lost the top place for the first time in a year! Or maybe not - the 95% confidence interval for the weekly hashrate of 50btc.com is +/- 500Ghps. Still, it's very close.
The top three pools' total hashrate is just over 50% of the total network hashrate for the first time in a while, and the network hashrate has dropped, too - along with another increase in difficulty.
You can view all charts at http://organofcorti.blogspot.com
Well, it seems that Deepbit has lost the top place for the first time in a year! Or maybe not - the 95% confidence interval for the weekly hashrate of 50btc.com is +/- 500Ghps. Still, it's very close.
The top three pools' total hashrate is just over 50% of the total network hashrate for the first time in a while, and the network hashrate has dropped, too - along with another increase in difficulty.
You can view all charts at http://organofcorti.blogspot.com
30th September weekly pool statistics
The big story this week has to be the first challenge to DeepBit's dominance - 50BTC.com has almost taken the top hashrate spot!
However, since 50BTC does not publish blocks stats or a hashrate history, 50BTC's current blockrate (170 blocks/week) means their weekly average hashrate 95% confidence interval is 2950 to 3987 Ghps - so they may have already beaten DeepBit's average weekly hashrate, or be not even close. Please provide a block history csv, 50BTC!
Thanks again to everyone who donated over the last fortnight - regular small donations help keep this ship afloat.
You can view all charts at http://organofcorti.blogspot.com
The big story this week has to be the first challenge to DeepBit's dominance - 50BTC.com has almost taken the top hashrate spot!
However, since 50BTC does not publish blocks stats or a hashrate history, 50BTC's current blockrate (170 blocks/week) means their weekly average hashrate 95% confidence interval is 2950 to 3987 Ghps - so they may have already beaten DeepBit's average weekly hashrate, or be not even close. Please provide a block history csv, 50BTC!
Thanks again to everyone who donated over the last fortnight - regular small donations help keep this ship afloat.
You can view all charts at http://organofcorti.blogspot.com
It wouldn't really show average hashrate of the pool's miners, since each pool will have slightly different formulas for determining when to adjust miner difficulty, and what to adjust them to. I think BTC Guild is fairly aggressive in terms of keeping variance low, so my target rate is still 1 share per 3-6 seconds. Other pools might only be targetting 1 per 10 seconds, or 1 per 20. Others might target 1 per second. These would lead to drastically different average difficulties, even though they may share the same miner speed distributions.
It just sounds like number porn to me. It doesn't really provide any meaning, it's just another statistic on the table.
It just sounds like number porn to me. It doesn't really provide any meaning, it's just another statistic on the table.
You mean you don't like number pr0n? Shame on you!
You are right though - if the same dynamic difficulty isn't used in each pool you can't compare one pool to another. You can compare a pool against it's history, though I'm not sure how useful that is. It gets a bit complicated and I dont have time to really think about it atm.
It wouldn't really show average hashrate of the pool's miners, since each pool will have slightly different formulas for determining when to adjust miner difficulty, and what to adjust them to. I think BTC Guild is fairly aggressive in terms of keeping variance low, so my target rate is still 1 share per 3-6 seconds. Other pools might only be targetting 1 per 10 seconds, or 1 per 20. Others might target 1 per second. These would lead to drastically different average difficulties, even though they may share the same miner speed distributions.
It just sounds like number porn to me. It doesn't really provide any meaning, it's just another statistic on the table.
It just sounds like number porn to me. It doesn't really provide any meaning, it's just another statistic on the table.
That's what I was thinking. The average D would be a good indicator as to whether a pool's hashrate consisted of many low hash rate miners, a fewer high hashrate miners.
I think it would be interesting as all get-out over time. It would show the average hashrate of users as an aggregate basically.
The Mining pools list and the table in this thread have both been correct using equivalent D1 shares from EclipseMC. I'll be correcting the other charts as I have time.
I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?
I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?
My particular setup (being PPS only) doesn't keep track of the difficulty of shares submitted (when logging to the database). When running at higher difficulty, I simply record high-diff submissions as multiple 1-diff shares.
Do you keep a record of total shares submitted before converting to D1 equivalent? If so I could calculate the average D. If not, there are just some stats that are not available for some pools - there's no standardised reporting of block history just yet.
Edit: But would tracking average D be interesting, in any case?
The Mining pools list and the table in this thread have both been correct using equivalent D1 shares from EclipseMC. I'll be correcting the other charts as I have time.
I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?
I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?
My particular setup (being PPS only) doesn't keep track of the difficulty of shares submitted (when logging to the database). When running at higher difficulty, I simply record high-diff submissions as multiple 1-diff shares.
I can add that to the API if you want, sure.
The Mining pools list and the table in this thread have both been correct using equivalent D1 shares from EclipseMC. I'll be correcting the other charts as I have time.
I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?
I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?
Ok... the API should report the correct amount of DIFF1 shares now. Is the metric of how many actual shares are submitted vs the DIFF1 equivalent useful for anything?
I think the API may not be correctly reporting Vardiff shares, I will take a look now.
Unfortunately I haven't heard back from the pool op about a data api. I'll add it as soon as I can get the relevant data though.
HHTT not added yet?
I'm not sure Eclipse looks right, either. Are my stats not coming out to you correctly? How are you calculating the hashrate exactly?
I'll look at the script and see what's happening. I sum the total shares and divide them by the total round duration. I've had to put in sanity checks to remove rounds of 0 shares - this could be a source of error.
I'm not sure Eclipse looks right, either. Are my stats not coming out to you correctly? How are you calculating the hashrate exactly?
Sorry I borked your BTC Guild stats this week ;p BTC Guild's stratum beta pool wasn't linked to the pool speed reporting, but the blocks were. Luck was actually terrible, and speed was up, rather than down . Luckily beta is over and now it all gets lumped together.
. Luckily beta is over and now it all gets lumped together.Thought that looked odd so I reviewed the script and found an error in my difficulty calculation which resulted in the current diff being applied to the week. Fixed that bug but I wouldn't have looked for it if the luck hadn't looked unusually good.
Sorry I borked your BTC Guild stats this week ;p BTC Guild's stratum beta pool wasn't linked to the pool speed reporting, but the blocks were. Luck was actually terrible, and speed was up, rather than down . Luckily beta is over and now it all gets lumped together.
. Luckily beta is over and now it all gets lumped together. Jump to: