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.

ghashio-ltc-pool-last-shifts-hashrate

After the end of the week long CexIO promotion with up to double rewards for their new Ghash LTC mining pool most of the users have left their pool, but still they’ve had about 7-8 GHS worth of mining hashrate remaining. Probably people that are mining there just because of the 0% pool fee, something that can easily be compensated if mining in pools with automatic alt coin switching based on profitability. Interestingly enough today the hashrate in the LTC mining pool has jumped to over 20 GHS with no apparent reason. The only way for this to happen is if some of the other larger pools is forwarding their mining hashrate via a proxy to the CEX mining pool, or if somebody is using a kind of man in the middle attach to do so and forward some pool’s hashrate to mine for his own account. So you might want to keep a closer look at your miners and profitability today in the pool you are currently mining at just to be sure. At the same time the total network hashrate for the Litecoin is showing some significant drop, so the next difficulty adjustment will most likely bring down the difficulty. This could however be a direct result of some new alt cryptos that are attracting a lot of users to switch to them due to significantly higher profitability than directly mining for LTC or with the potential for such.

Update: It seems that after passing 30 GHS total LTC pool hashrate the Ghash.io mining pool is starting to have issues again, though it is possible that they might be getting DDoS attacks as well as apparently other mining pools do at the moment. This is creating problems not only for the LTC mining pool, but for the BTC mining pool there as well. So it might be a wise idea to move to another pool if you are mining there at the moment in order to avoid possible downtime. Of course you should have multiple backup pools available in order to be able to handle such problems without any downtime, but many people still seem to set just a single mining pool in their miners. And while at the moment Ghash.io is having trouble and you might just see a CloudFlare warning instead of the actual pool website, the other “main” website of the service CexIO seems to be running just fine. It is not very clear what is happening with the people that have purchased cloud mining hashrate for the moment, but since the pool is down it is possible that the mining hardware for the cloud mining service might not be able to operate as well, though in such cases the users are usually getting compensated for the downtime of the cloud mining hashrate by the service after the issue is resolved. And it seems the downtime was very brief and the service is starting to get back to normal…

kraken-logo

If you have initiated a withdraw request at the Kraken crypto currency exchange around 17th of March and you still haven’t received the money you might want to contact the support. It seems that there might’ve been some problems with the bank servicing the payments at around that time, and withdraw requests made earlier or later might not be affected at all. So if you are still waiting for your money and you have made a withdraw request around that date you might want to contact the support in order to resolve the issues as some users have already reported having a problem. Below is a quote from a response from Kraken’s support regarding the issues:

We have noticed that a few of our users are waiting for withdrawals with the status “success” sent on the 17th March, even though withdrawals initiated after that has arrived. Something is definitely wrong and we are investigating this with our bank, I’m sorry for the delay, don’t worry your funds will show up in your account as soon as we have found the cause of this delay and fixed it.

Our guess is that it is a problem with the banks API, there has been problems with that in the past, and they are examining the API issues and will return to us with more information.

This issue has only affected withdrawals initiated around the 17th of March.

So far our experience with the Kraken crypto exchange has been very positive and they are really fast in servicing withdraw requests, so we are expecting that this issue will quickly be dealt with and the users that had problems with their transfers will soon get their money available in the bank accounts.

top