Posts Tagged ‘cgminer’

How to Effectively Mine on Multipe Vardiff Pools

26, Feb 2015

cgminer-pool-management-strategy

If you have a not so powerful mining rig or and ASIC and you want to be able to effectively mine on multiple pools that use variable difficulty instead of a fixed one it might be a bit of an issue. Usually on vardiff pools you start with a lower difficulty that might be right for the hashrate of your mining hardware, but the pool starts to increase the difficulty over time making it hard for your miner to keep up to its maximum performance, especially if using multipool that switches coins or solves blocks quickly. CGminer and the other alternative mining software products do come with strategies for effectively utilizing multipool scenarios, you just make sure you use the right one depending on your situation. By default the multipool strategy used by the mining software is set to failover, meaning that if the first pool stops responding the miner will move on the next one in the list until the higher priority pool is back online.

Obviously the above default scenario does not work for vardiff pools to keep your miner at the recommended lower difficulty level, so you need to use one of the different strategies in order to be able to do that. The right strategy for using multiple vardiff pools is the rotate strategy where the miner will automatically switch between the list of pools based on a user set time interval. So checking what time it requires for the pool to switch from the initial difficulty of lets say 128 to 256 and then to move to 512 will give you an idea on how many minutes you need to set for the rotate rounds. 128 and 256 difficulty is OK for Bitcoin ASIC miners that are in the range of 150-200 GHS for example, so setting lets say 5 minutes for the rotation interval should prevent the pool to go higher than 256 difficulty. What the miner will do is move to the next vardiff pool in the list for 5 minutes and then get back to the first pool for 5 more minutes and so on, keeping a difficulty of 128-256 on both pools. This is a great strategy for using with NieHash and WestHash for selling your SHA256 hashrate for example if you have a not so powerful ASIC miner.

Changing the multipool strategies is possible from within the already running cgminer or another miner forked from it or with support for the same options, but this will not be permanent – it will function until the restart of the miner. You can also set the rotate mode to be activated with a startup parameter of the miner by adding this to the command line --rotate 5, the example is for 5 minute rotation between the list of pools.

Download sgminer 4.2.1 Scrypt GPU Miner for Windows

1, Jun 2014

sgminer-4-2-1-windows

We got a request for an up to date windows binary of the latest official sgminer 4.2.1 (source), so here it is. Do note that this is the standard version of sgminer that in intended for Scrypt mining and does not support a lot of alternative crypto algorithms, for that you will need to get sph-sgminer, a fork based on an older version of the official sgminer, namely sgminer 4.1.0. From the link below you can download the latest sgminer 4.2.1 Scrypt GPU miner for windows.

– You can download sgminer 4.2.1 with Scrypt GPU support for Windows OS here…

What is the Actual Hashrate You Get from Your Gridseed ASIC

24, Mar 2014

bfgminer-gridseed-actual-hashrate

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.

cgminer-gridseed-actual-hashrate

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.

gridseed-asic-miner-pool-hashrate

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.


top