Topic: Weekly pool and network statistics - page 21. (Read 91451 times)

I think placing confidence bounds on the network hashrate estimate help people understand that the estimates they see on websites are influenced significantly by the network luck. If there's a dip from 25000 Ghps to 20000Ghps, how much is luck and how much is an actual reflection of work being done? If it's based on a daily hashrate average, the 95% confidence interval for luck is ~ 4Ghps, so a 5Ghps drop in daily average hashrate might only be a 1 Ghps drop.

It gets much worse for hourly hashrate estimates which can have a 95% confidence interval of about +/- 36%. I wish websites would give an error guide to the estimates they produce. Some miners seem to get panicky quite easily.

I really like the Lower/Mean/Upper hashrate estimate figures for the week.

Nice job on the charts

I do like the charts
Our stratum + vardiff setup is working very nicely and is bringing new miners and some old miners returning

Like the new charts? I noticed Ozcoin was the only pool to grab an appreciable portion of the network hashrate this week

love your work 

Errr ... I don't like December?

Fixed, but left something there for posterity.

I'm not sure what it says about me, but I heard that in my head in Homer Simpson's hoarse whisper.

2nd November December weekly pool statistics

Welcome, miners.

I spent most of the week rewriting scripts for accuracy and to fail better. I'm quite happy with the results. I also made the "week" boundary much firmer by only including blocks after the first block last Sunday (UTC) to the last block Saturday (UTC). The blocks are included in the first table title.

Changes:
Figure 1: Table
I  removed data that no one was interested in, and added more pertinent data. I've included network statistics, handy if you're comparing a pool's performance to the network's performance in general, and  I added the CDF so that the "shares per round / D" makes a bit more sense, and added the upper and lower 95% confidence intervals for the Network and 50BTC.com hashrate estimates. I did this since I noticed on the bitcointalk.org forum many posters confusing the daily or hourly network hashrate estimates for the actual number of hashes submitted. This is of course impossible, and after trying to explain why a few times, I thought it might be useful to just include the upper and lower 95% confidence interval for the estimate in the stats.


Figure 2:
The upper and lower 95% confidence intervals for the Network hashrate estimates are the shaded areas of the plot. It makes it much more obvious that the top three pool hashrates combined have been around the 50% of the network hashrate for quite a while - not that it matters greatly.
Figure 3:
Only the top ten pools are included. This way the chart is easier to read, and I don't have to use a log scale. I'm still collecting the data for the smaller pool if at some point in the future their hashrates increase and bring them into the top ten.

Figure 4:
The network average hashrate per 144 rounds is included, along with a shaded 95% confidence interval.

Figures 5, 6, 7, 8:
No changes to the display of the data.

Let me know what you think of the changes, and if you'd like the data they're based on pasted somewhere.

You can view all charts at http://organofcorti.blogspot.com

Thanks for the kind thoughts both of you. Part of this is probably my fault, since I've spent much more time writing scripts to scrape webpages than I have actually encouraging pools to provide a .csv of round history.

My script for bitparking, (which has a great .csv of round history, includes Difficulty, round duration etc)  is now down to two lines. My script for Bitcoinpool is around a hundred lines and needs nursing. No more! I'll spend my time making sure the stats are accurate, and the tables and charts more useful and legible.

For next week I'm also removing % network blocks, and the  historical chart of % network hashrate is going to be top 10 only. I hope it makes the data a bit easier to follow.

Vote to remove your least favourite chart here!

+1

That certainly is understandable.

I really appreciate your effort in this table of stats.  I'm starting to really enjoy checking it out and keeping better tabs on the pools.
I think this topic should be pinned below your mining pools list.
Thanks,
Sam

25th November weekly pool statistics

Welcome, miners.

First, some sad news. I have been spending far too much time every Sunday fixing bugs - mostly relating to HTML scraping and sometimes to do with abnormal data from pools. I can't justify the amount of time I spend on this to my family, so I have to make some hard choices.
I will not be continuing to update stats for pools that only provides round history on a https protected page, if that pool's page starts to throw errors. If the pool wants to provide a .csv of round history, then I'll be happy to include them again.
Any statistic or chart of which I cannot be confident I will not be continuing.

This week, we unfortunately must say goodbye to Coinotron. I hope we see them again soon, once a round history api is available. Also, I won't be including BTCGuild's hashrate per day in the hashrate per round charts, since that data is easily available from the pool's website, in a much easier to use format and with a longer history.

Also this week we say goodbye to the "orphaned blocks" charts. It has been pointed out to me that the data on orphaned blocks I get from many pools do not match the information compiled elsewhere.

Hopefully, trimming down pools that require excessive time to manage and charts which may not be accurate will give me time to do some overdue code rewrites. My aim is to be able to run the scripts automatically - and right now this is not possible most of the time. I'd also like to work on a few sanity checks - I hadn't realised there could be such significant errors in timestamp reporting as there were this week, one pool reporting timestamps that were three months before the current time.

Finally, an interesting fact this week - Deepbit does not seem to be suffering from poolhopping at all as far as I can see, and the "pool hopper loss" chart (which is only an estimate) agree with this. Nice work, [Tycho]. I do hope it lasts for you.

You can view all charts at http://organofcorti.blogspot.com

Yes, afaik they don't publish pool stats, so I have no idea what they're doing. I don't think they would have nearly 2Thps though.

I am really curious where the hashpower coinlab is getting ends up.

18th November weekly pool statistics

Welcome, miners.

Something quite strange happened this week. The weekly average network hashrate dropped by almost two Thps. At the same time, the percentage of the network hashrate for each of the top seven pools rose significantly, in some cases reversing longstanding downward trends. The smallest of the top seven, Ozcoin is at ~ 1Thps.

In order for this to occur, some of the network hashrate went offline this week without affecting the larger pools at all, so none of it was from miners at the larger pools. As far as I can tell, the smaller pools that lost hashrate did not lose a total of ~ 2 Thps. So this loss in network hashrate must be from one or more solominers.

My suspicion is that some testing of ASICs has occurred and has now ended. Perhaps it was thought that by gradually adding hashrate no one would notice the increase, but they didn't think about gradually ending testing, hence the rapid decline. And it wouldn't be particularly noticeable if the historic charts of pool % of network hashrate were not available.

Anyone have other ideas?

Feel free to comment. I'll try to reply, but I've just realised there's some blogger.com problem preventing me from reply at the moment. I hope to get it fixed soon.


You can view all charts at http://organofcorti.blogspot.com

hehe actually the extra hashrate is ALL on the new stratum servers, ecoinpool nodes are maintaining hashrates
I am expecting vardiff to bring more users to stratum nodes

11th November weekly pool statistics

Welcome, miners.

Ozcoin finds a very mysterious 500Ghps gradually over about 5 days this week. This means an in crease in average hashrate of about 250 Ghps, and an increase in percentage of network hashrate. Someone received an early ASIC shipment? /tinfoilhat

The obvious increase in pool hopping at Slush's pool maybe the reason for their increase in network hashrate this week.

Every thing I wrote about BitMinter last week still stands, except I think their luck and increase in hashrate maybe due to technomancy rather than human sacrifice. I'm not completely sure, though.


Apart from Ozcoin, BitMinter, and Slush's pool, all the other large pools lost a percentage of network hashrate.

Bitlc.net, Triplemining, and Mkalinin are missing this week due to a mix of lack of block solves and an update to RCurl that seems to have messed up some of my scripts. Note to self: Test scripts after a major update in R.


You can view all charts at http://organofcorti.blogspot.com

4th November weekly pool statistics

Welcome, miners. The top story this week is DeepBit's very strange drop in hashrate mid week. Is this because of DeepBit's well known attempt to remove pool hoppers from the pool, or something else? The loss to pool hoppers chart will be inaccurate for DeepBit this week due to the large change in base hashrate.

BitMinter continues to increase it's share of the network hashrate, one of the only pools to see a significant increase in hashrate this week. They also continue to have good luck. Suspiciously good luck. I suspect human sacrifice to the god of the blocks may be the answer here.

BitcoinPool did not solve a block this week and so are not listed.

You can view all charts at http://organofcorti.blogspot.com

Because polmine does not provide a round history API. If they would like to provide me with a .csv API then I'll be happy to add them. The API should provide the following data in a .csv format: