16th July 2013
0. Introduction
Not too many changes this week. The network hashrate continues to increase, and the number of miners and the electricity consumption are stable. In lieu of anything interesting to say about the update, here are a few obvious inaccuracies that you may have noted:
1. ASICMiner's hashrate vs the proportion shown in chart 1.
You'll notice that although ASICminer's hashrate is between 35 and 40 Thps this week, chart 1 shows a total of double that in the same range. This is an example of inaccuracy due to the sample of pools used.
The pools I can sample for user hashrate only make up 51.2% of the current network hashrate. My simple method of scaling this to the network means that low numbers of large hashrate producers (eg ASICMiner) will appear to have more of the network hashrate than they actually do - and also decrease the estimate of the network's electricity use. I plan to fix this for ASICMiner, but a general fix is not possible.
2. Blades and GPUs.
For the 6 to 20 Ghps range I assumed that any new increases in hashrate would come from ASICs. However I have not found a way to start removing GPUs as they become less profitable - as can be seen from the 10 to 49 Ghps band, which is continually increasing. This could cause an increase in the estimate of the network's electricity use
3. What about the survey?
The survey will help with estimations of the percentage of given hashrate bands that are produced by particular devices. However there's a large amount of data sanitising that needs to be done - the odd character in a numeric field is not so much a problem, but some respondents have randomly mixed their gighashes with their megahashes, and I have to change each one manually from context. Each night I sort though one or two responses, so it could be a while before I've finished.
1. ASICMiner's hashrate vs the proportion shown in chart 1.
You'll notice that although ASICminer's hashrate is between 35 and 40 Thps this week, chart 1 shows a total of double that in the same range. This is an example of inaccuracy due to the sample of pools used.
The pools I can sample for user hashrate only make up 51.2% of the current network hashrate. My simple method of scaling this to the network means that low numbers of large hashrate producers (eg ASICMiner) will appear to have more of the network hashrate than they actually do - and also decrease the estimate of the network's electricity use. I plan to fix this for ASICMiner, but a general fix is not possible.
2. Blades and GPUs.
For the 6 to 20 Ghps range I assumed that any new increases in hashrate would come from ASICs. However I have not found a way to start removing GPUs as they become less profitable - as can be seen from the 10 to 49 Ghps band, which is continually increasing. This could cause an increase in the estimate of the network's electricity use
3. What about the survey?
The survey will help with estimations of the percentage of given hashrate bands that are produced by particular devices. However there's a large amount of data sanitising that needs to be done - the odd character in a numeric field is not so much a problem, but some respondents have randomly mixed their gighashes with their megahashes, and I have to change each one manually from context. Each night I sort though one or two responses, so it could be a while before I've finished.
The raw user hashrate data is here. It's an Rdata file, and consists of a dataframe named "alluserHR.df" with 232111 rows and three columns - Date, Pool (this includes ASICMiner), and UserHR (the hashrate of pool account holders in Ghps). Let me know if you do something interesting with the data.
1. Network: Per Ghps band user count, summed hashrate, and summed electricity.
2. Pools: Per Ghps band user count, summed hashrate, and summed electricity.
Most pools are experiencing declines in the numbers of users in the < 5 Ghps band.
3. Efficiency, joules per Gh (eq. watts per Ghps)
This chart is not meant to be a value judgement on any pool; rather you can think of the efficiency as a guide to the proportion of different types of hashing tools. The higher the J/Gh, the less efficient the hashing entity is (pool, network or solominer), and the higher the proportion of CPUs and GPUs to ASICs.
Since there can be significant variance per week I'm using cubic splines, so curves may vary from week to week.
organofcorti.blogspot.com is a reader supported blog
BTC: 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
LTC: LPXnETNoCBr16GduvyWRzFP83rZNeEgMuB
For notification of new posts, follow @oocBlog
No comments:
Post a Comment
Comments are switched off until the current spam storm ends.