What is the Actual Hashrate You Get from Your Gridseed ASIC

24 Mar


It seems that many users are having trouble understanding what is the actual hashrate they get from their 5-chip Gridseed ASIC miners, the reason for that is partly related to how the Gridseeds are handles in different miner software and the difference in what is being reported. We are starting with the bfgminer 3.10.0 with Gridseed support running a single unit – see the screenshot above as the example that we are going to talk about. Note that the bfgminer has just been started and there are 11 accepted shares, 2 rejected and 0 hardware errors. The first number showing 361.2 KHS is the local hashrate of the miner (running at 850 MHz), this is calculated based on the frequency the miner is running at and is the hashrate that you should be getting in ideal conditions, however normally the conditions differ. The actual hashrate you are getting is the third number, the one we have marked in red, so that you can clearly see what we are talking about. That third number shows the actual hashrate based on the number of accepted shares and their difficulty, it takes into account the rejected shares and the hardware errors you get. The number is calculated as an average since you have started the miner software. The question that you are probably going to ask is why if in ideal conditions we should be getting 361.2 KHS here we have 426.7 KHS as actual hashrate. The reason for that lies in the fact that we just had 11 shares accepted and we had luck so that their difficulty was below the average, so the reported hashrate is averaged over a very short period of time and is not what we should be getting in the long run. You need to leave the miner run for a longer time in order to have a better representation of the actual hashrate you will be getting, but in the long run you are most likely going to get a result that is a bit lower than the optimal value of 361.2 KHS.


In the second example we are going to be looking at cgminer 3.7.2 modified to support Gridseed. In the example above we have a single miner overclocked to run at 950 MHz and the software miner has been running for a few hours already. Again the first number that shows 404.3 KHS is the theoretical hashrate in ideal conditions that is based on the operating frequency of the miner. The second number that we have marked with red is the actual hashrate that we are getting with this ASIC device running cgminer. The second number takes into account the time the miner is running, the number of accepted shares and their difficulty, the number of rejected shares and the hardware errors the device is getting. So instead of 404.3 KHS the actual hashrate we are getting is 401.5 KHS in this case and this is the result we are getting with the cgminer running for 4 hours.


If we take a look at the hashrate reported by the pool for the Gridseed ASIC miner using the cgminer example above we can see that the pool reports 398.46 KHS and not 401.5 KHS. The number of submitted shares and rejected ones reported by the pool is also different. The reason for that is that the pool statistics has been reset about 8 hours before starting the miner and the statistics in cgminer is for about 4 hours only. The reported actual hashrate of cgminer is based on 4 hours of running, however the reported hashrate by the pool is based only on the shares submitted in the past 1 hour. Different mining pools base their average hashrate on the number of shares submitted in the last X minutes and that period can vary between 1 minute to 1 hour or even more. And as with the software miners not being able to report very adequate hashrate in just a minute or two, if the pool reports hashrate based on the shares submitted over a short period of time it might be reporting lower or higher values that are not close to the real one. Looking at the right number in bfgminer or cgminer should give you a pretty good idea on the actual hashrate you are getting, also pools that average hashrate over a longer period of time such as at least 5 or 10 minutes can be used to give you a good idea.

The first miner available with support for the Gridseed ASIC devices was a modified version of cpuminer that however does not report local or actual hashrate as that software miner does not keep statistics for the number of accepted and rejected shares, neither does take into account the hardware errors produced by the device. So it reports a hashrate of 0 all of the time, even though it is actually working, the only way to find what is the actual hashrate if using cpuminer is to look at the hashrate reported by the pool.

Other Similar Publications:

20 Responses to What is the Actual Hashrate You Get from Your Gridseed ASIC


March 24th, 2014 at 21:19

Great post – not just for the Gridseeds, but any miner you use. People are entirely too confused by the numbers on the screen – relatively poor documentation of the screen (the flags/options are generally well-documenteD) doesn’t help.


March 24th, 2014 at 21:47

Which miner is recommended?


March 24th, 2014 at 21:49

Matt, it is more a matter of preference if you use bfgminer, cgminer or cpuminer, though cpuminer is the most basic and we do not recommend to use it now that we have cgminer and bfgminer with support for Gridseed ASICs.


March 24th, 2014 at 23:02

if you look at gridseed modification thread on bitcointalk, and look at wolfey, he did all the mods on his gridseeds,
pencil, resistor, and bridge.
He is actually runing his GS’s at 1000mh/z and getting out close to 600kh/s !


March 24th, 2014 at 23:21

jamie, don’t get over excited. There is no way to get 600 KHS with a 1000 MHz frequency on the Gridseed! This is just a clear example of our explanation how people that are not aware of things seem to think of getting and reporting wrong results – hashrate reported by the pool and for short period of time with some lucky small shares. Reporting things like that without knowing too well may mislead people and you are a clear example. The actual realistic hashrate you can expect with 1000 MHz overclock is about 425 KHS not 600…

Just like that somebody may overclock to 1150 MHz and report he is getting 500 KHS, without noticing the fact that the miner may actually not send any shares and get only HW errors, the miner however will say 500 KHS local hashrate.


March 25th, 2014 at 04:38

thanks for the rectification, I see clear now


March 25th, 2014 at 22:58

I have 1 Gridseedminer running a few days. Incidentally, I have a R9 280X which serves as a reference.

The Gridseed has loud gcminer about 360 KH / s and the R9 280X 720 KH / s.
The Gridseed has produced 124000 TIPS in about 24 hours. The R9 280X contrast 523000 TIPS.

The gridseed with 360 but should provide about half, in contrast to R9 280X. But he creates just one quarter.

I have the WinUSB driver installed with zadic.
And I get a lot of HW Errors, over 1000 ind 24 Hours.

What’s the problem? Can you help me?


March 25th, 2014 at 23:17

ToBi, try to lower the operating frequency to see if the HW error rate will decrease, you are probably running at 850 now. If you have a high pool difficulty try to lower it for the Gridseed worker, is the number of rejects also high?


March 26th, 2014 at 00:17

Hi Tobi,
I would look at this bitcointalk thread, Wolfey has a very good experience with the GS’s he also have them runing overclocked
I have also seen today that the best diff to put on the pools for a gridseed is 64 or in wafflepool password d=64


March 26th, 2014 at 00:28

whats is the power consumption of these per unit is it 7 watts per unit? and what is the actual product number for the gridseeder you purchased?


March 26th, 2014 at 00:39

The Pool-Diff is at 64, the rejects are also very high (more than HW-errors). I will decrease the frequency and try this.


March 26th, 2014 at 00:49

The power consumptio is 6 watt. I use the gcminer 3.7.2 oc – version from cryptmining-blog. And the product number – it don’t know whrer to find – gcminer shows: 8D78489C4849


March 26th, 2014 at 21:47

How can we get changes made to cgminer so it recognizes the gridseeds reliably on start up? Right now I have to start cgminer up with 1 gridseed plugged in and then plug in all the others.


April 8th, 2014 at 14:01

One of my miners looks quite lazy conpared to the rest. I tried different clock speeds but it seems to always be lazier than the other ones. Look at the shares accepted and wu:
[P]ool management [S]ettings [D]isplay options [Q]uit
GSD 0: 8D76425D5748 850 MHz | 360.1K/359.4Kh/s | A:455816 R:8703 HW: 6 WU: 1.8/m
GSD 1: 6D7536A84853 850 MHz | 360.2K/359.5Kh/s | A:462799 R:9493 HW:10 WU: 1.8/m
GSD 2: 6D7248784857 850 MHz | 360.2K/359.5Kh/s | A:174226 R:3690 HW: 3 WU: 0.7/m
GSD 3: 6D71107B4853 850 MHz | 360.3K/359.4Kh/s | A:459029 R:9653 HW: 7 WU: 1.8/m
GSD 4: 6D8424864857 850 MHz | 360.3K/359.3Kh/s | A:452959 R:8410 HW:11 WU: 1.8/m
GSD 5: 6D7B23894853 850 MHz | 360.3K/359.2Kh/s | A:447927 R:9650 HW: 7 WU: 1.7/m
GSD 6: 6D96527C5748 850 MHz | 360.2K/359.1Kh/s | A:445316 R:9589 HW:15 WU: 1.7/m
GSD 7: 6D72519B5748 850 MHz | 360.1K/358.8Kh/s | A:447510 R:7544 HW:14 WU: 1.7/m
GSD 8: 6D75505B5748 850 MHz | 360.2K/358.8Kh/s | A:451649 R:7392 HW:16 WU: 1.8/m
GSD 9: 6D70369F5748 850 MHz | 360.2K/358.9Kh/s | A:442447 R:8132 HW:21 WU: 1.7/m

What can I do to make it perform like it’s supposed to?


April 9th, 2014 at 23:25

mightyminer, Have you tried restarting the miner software to see if that device will behave like that again or not?


April 10th, 2014 at 16:17

Yes that’s the first thing I tried. I tried unplugging the usb hub. I tried rebooting the pi and plugging the miners in a different computer. That single miner is the only one which procrastinates.


April 10th, 2014 at 16:43

mightyminer, we’ve seen similar behavior with some of our miners, when exiting the miner it usually gives out a Lubusb error for the “slow” miner and running the miner software again usually fixes the problematic miner.


April 14th, 2014 at 13:52

I tried different possibilities. Ubuntu, raspbian, girnyau and dtbartle cgminer builds on each. Always the same bad behaviour. I think the unit is faulty and the IC that controlls all the 5 asic chips reports the clock settings for the whole miner as expected but then some of the individual asic chips don’t work as they should.


April 14th, 2014 at 14:06

mightyminer, have you tried running the miner at a lower clock speeds to see if it will be stable?


August 30th, 2014 at 15:23

admin what are you mining by that time? :D tell me! :) please! :)

Leave a Reply

Your email address will not be published. Required fields are marked *