<p>This happens with all pools. Some pools measure over a long time and get a fairly accurate hashrate, but it is very slow to react to changes (stop mining, add hashpower, etc.). Other pools measure over a short time and get a more inaccurate hashrate, but one that reflects changes faster.</p>

<p>The estimated hashrate isn't affected much by rejected work, unless you have an abnormal amount of those. If you have a lot of hardware errors (miscalculations) from your devices, those can also affect it some. These two issues can give a persistently lower hashrate than you are actually hashing with. But the source of the swings up and down is primarily the randomness with finding proofs of work. Some nonce ranges you scan will contain 3 and some won't have any at all.</p>

<p>Mining with a higher worker difficulty will increase the variance with finding proofs of work. If you set a worker difficulty that is very high for your hashrate then the website's estimate of your hashrate will likely be all over the place.</p>

<p>For a more accurate estimation of your hashrate look at your average hashrate per shift or other longer term, rather than a live hashrate estimate.</p>

<p>So there is really no specific answer to how accurate an estimated hashrate should be. Different pools use different methods, and some even have different hashrates in the same pool (measured over short and long periods of time).</p>

CC BY-SA 3.0
2014-03-23T09:27:21.743Z
2014-03-23T09:27:21.743Z
Dr.Haribo
<p>I'm playing around with a few USB miners, and am running 4 of them for a total of 4.6 GH/s.  My BTCGuild dashboard estimation is all over the place, sometimes 1 GH/s, sometimes as high as 3.8 GH/s.  Overtime I expect it to converge to some value, but that hasn't seemed to happen.</p>

<p>It's my understanding that this number is just an estimation and will be affected by stale/duplicate shares my machine submits, but how stable should this estimation be?</p>

<p>Is the volatility of this estimate a product of the PPLNS scheme or could there be something strange with my setup?</p>

<p>How does my difficulty setting with the pool factor into this?</p>

<hash><bfgminer><mining-pools><btcguild>
How accurate should pool estimation of hashing speed be?
John Carter
# How accurate should pool estimation of hashing speed be?

(Asked by: username_0 on 2014-03-23)

I'm playing around with a few USB miners, and am running 4 of them for a total of 4.6 GH/s. My BTCGuild dashboard estimation is all over the place, sometimes 1 GH/s, sometimes as high as 3.8 GH/s. Overtime I expect it to converge to some value, but that hasn't seemed to happen.

It's my understanding that this number is just an estimation and will be affected by stale/duplicate shares my machine submits, but how stable should this estimation be?

Is the volatility of this estimate a product of the PPLNS scheme or could there be something strange with my setup?

How does my difficulty setting with the pool factor into this?

**Tags:** hash, bfgminer, mining-pools, btcguild


---

## 1 answers

### Answer by username_1 on 2014-03-23. Score: 1 | Accepted answer

This happens with all pools. Some pools measure over a long time and get a fairly accurate hashrate, but it is very slow to react to changes (stop mining, add hashpower, etc.). Other pools measure over a short time and get a more inaccurate hashrate, but one that reflects changes faster.

The estimated hashrate isn't affected much by rejected work, unless you have an abnormal amount of those. If you have a lot of hardware errors (miscalculations) from your devices, those can also affect it some. These two issues can give a persistently lower hashrate than you are actually hashing with. But the source of the swings up and down is primarily the randomness with finding proofs of work. Some nonce ranges you scan will contain 3 and some won't have any at all.

Mining with a higher worker difficulty will increase the variance with finding proofs of work. If you set a worker difficulty that is very high for your hashrate then the website's estimate of your hashrate will likely be all over the place.

For a more accurate estimation of your hashrate look at your average hashrate per shift or other longer term, rather than a live hashrate estimate.

So there is really no specific answer to how accurate an estimated hashrate should be. Different pools use different methods, and some even have different hashrates in the same pool (measured over short and long periods of time).


---

