Pages

▼

Sunday, 3 November 2013

November 3rd 2013 weekly pool and network statistics




Other weekly pool and network statistics posts


Welcome, miners.

Changelog:
  • Updated the table and all charts but the user hashrate density chart to Thps. User hashrates are still best measured in Ghps.
  • "Unknown" has been in the pie chart for a while; now I've also added it to the table, along with confidence intervals for the hashrate.
  • Pie chart has been changed to be prettier (and hopefully easier to read).
  • Pool hopping chart for Deepbit has been changed to include the last ~128 days. I'll reduce this if Deepbit's share of the network rises again.
Usual pools missing from results:
  • 50BTC - no blocks solved this week.
Errors:
  • Nil
Pools with coinbase signature:
Recent coinbase messages:

Pool hopping:
  • Nil.

 1. Network drops back to solving 1330 blocks during the past week.
Since February this year, (the start of the ASIC induced network hashrate increase ) ~ 1200 blocks have been solved per week, (8.4 minutes per block). For the last couple of weeks as KNC miners were delivered, the network was solving ~ 1500 blocks per week (6.72 minutes per block). Now, the network has returned to its previous background acceleration - until the next batch of ASICs ship.

2. 50BTC at 4Ghps.
Almost no one is mining at 50BTC - after the last announcement, I guess they're waiting to see what happens next.

3. Eclipse and Polmine: Ups and downs, again.
(see figure 4) I've noticed Eclipse's bouncing hashrates for a while now. It's not beyond reason that the 40Thps spikes this week could be due to intermittently added hashrates. However, the hashrate changes per block that Polmine has been experiencing must be due to data error:

        Date        Thps
1 2013-10-29   2.9978219
2 2013-10-30   3.0793512
3 2013-10-31 147.9324923
4 2013-11-02   0.2168786
5 2013-11-02 101.8922103

I haven't been able to figure out what the problem might be just yet.

4. Proofread for me.
Most of my posts are completed around 2am, and when it's late my proofreading abilities are somewhat poor. Plus my spacebar seems to be sticking and I don't always notice it. So if you find a typo or spelling error in my blog posts, email me the error or errors (highlighted in red) and if you're the first to email them, I'll pay you per error U$ 0.50, or per ten errors:




Organofcorti lives! (thanks to Eclipse )

As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong.

The charts

Table: Table of all pools with public data and their various statistics averaged for the last seven days - for smaller pools the average may be more or less than seven days, depending on number of blocks solved for the week. Network hashrate and that of some pools are estimates, the upper and lower 95% confidence interval bounds are included.
Figure 1: Pie chart of the percentage of network blocks hashrate by pool. "Unknown" combines those pools for which I can't scrape statistics, solominers and private pools. The percentage of network hashrate will only be approximate since the exact network hashrate is unknown.
Figure 2: Chart of network hashrate, hashrate of the largest mining pool, combined hashrates of the three largest mining pools, and a line representing 50% of the network hashrate. Handy if you're worried about 51% attacks. The upper and lower 95% confidence interval bounds for the network hashrate are in between the shaded areas.
Figure 3: Chart of chronology of pool hashrates, averaged per week.
Figure 4: Chart of average hashrates per pool per round for the week, per 144 rounds for the network, and per hour for BTCGuild. The upper and lower 95% confidence interval bounds for the network hashrate are in between the shaded areas.
Figure 5: Chart of chronology of negative binomial CDF probability of shares submitted and blocks produced for the week.
Figure 6: Chart of chronology of round length divided by difficulty, averaged per week.
Figure 7: Chart of hashrate vs round length for hoppable pools (the larger the hashrate increase at the start of a round, the larger the loss to strategic miners).
Figure 8: Chart of pool user hashrate distribution. Note that for some pools this average is over twenty four hours, some pools are averaged over an hour or more and some for only fifteen minutes, so expect some variance in the results.













Thanks to blockexplorer.com for use of their network statistics.

organofcorti.blogspot.com is a reader supported blog:

12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r

Find a typo or spelling error? Email me with the details at organofcorti@organofcorti.org and if you're the first to email me I'll pay you per error:
 

I'm terrible at proofreading, so some of these posts may be worth quite a bit to the keen reader.


<weeklypoolstatistics>

at

2 comments:

  1. lenny6 November 2013 at 09:11

    Polmine's spikes in hashrate happening, because main server is running out of processing power. Right now, according to main pool operator - megavega, background thread is processing backlog of accepted shares during last couple of days, process has reached 60% so far. That's why hashrate right now seems to be higher than it's really is, and was reported lower than it really was in last couple of days.

    ReplyDelete
  2. organofcorti8 November 2013 at 23:00

    Thanks lenny. The hashrate spikes have been present since the start of the data I have - so has this been a constant issue for Polmine?

    ReplyDelete

Comments are switched off until the current spam storm ends.