Posts Tagged ‘cpuminer


Gridseed ASIC users will be happy to learn that there is a new fork of the cpuminer software with support for Gridseed ASIC miners (for Scrypt only mining) thanks sandor111 over at the Bitcointalk forum. He has added support for local hashrate reporting which was one of the key missing features of the previous builds, but he did not stop at that, he has also added support for per chip frequency autotuning (automatic overclock until the best frequency is reached for each chip) and the ability to manually set frequency for each miner by using a single instance for multiple devices. There is also support for the new Gridseed G-Blade miner, you only need to set the number of chips to 40 for each of the PCBs of the Blade Miner in order for the local hashrate to be properly reported.

We have compiled a windows binary of the new miner and you can find the source here. Great work and essentially what the original cpuminer should’ve been from the start, and now it is finally here, simple and easy with all the right features available. We are currently testing the new miner, especially the autotune feature, so far it seems to work quite well, but be aware that it could take some time for the miner to adjust frequencies, so make sure you set a starting frequency that is closer to what you expect that the device should be capable of. For example 850 MHz for default non modified 5-chip ASIC, 950 MHz or 1150 MHz if you have dome some sort of a voltmod already. Do check the included Readme file for a description of the options and some examples as well as for a simple, but effective Batch script for using backup pools with the miner. If you find some problem or an issue using the miner please do report it, so that it can be addressed.

You can download the sandor111 fork of cpuminer for the 5-chip GC3355 ASICs for Windows OS here…


We have updated our windows builds of the cgminer 3.7.2 and cpuminer for Gridseed 5-chip GC3355 ASICs and you can download them below. Both versions include the latest official releases (cgminer source and cpuminer source) and in the source folder you can find our modified files for adding additional frequencies for overclocking if you want to compile from the source code yourself.

Both the cgminer 3.7.2 and cpuminer with Gridseed 5-chip GC3355 ASIC support the following frequencies that you can set to find what works best for overclocking the devices you have:

250, 400, 450, 500, 550, 600, 650, 700, 706, 713, 719, 725, 731, 738, 744, 750, 756, 763, 769, 775, 781, 788, 794, 800, 813, 825, 838, 850, 863, 875, 888, 900, 913, 925, 938, 950, 963, 975, 988, 1000, 1013, 1025, 1038, 1050, 1063, 1075, 1088, 1100, 1113, 1125, 1138, 1150, 1163, 1175, 1188, 1200, 1213, 1225, 1238, 1250, 1263, 1275, 1288, 1300, 1313, 1325, 1338, 1350, 1363, 1375, 1388, 1400.

You can download the latest cgminer 3.7.2 ALT for Gridseed ASICs on Windows OS here…
You can download the latest cpuminer for the 5-chip GC3355 ASICs for Windows OS here…


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.