<p>The standard getwork protocol forces the miner to send a new request every second. This means that if a miner takes longer than 1 second to check all nonces in a given getwork (2^32), it will be making a new request before it checks all values in a given request, thus giving you 1 getwork request per second regardless of the hashrate.</p>

<p>If the miner can solve the getwork faster than that, it would be making requests more often. In theory, you could use this formula to calculate the hashrate:</p>

<p><code>Hashrate = noncemax/time</code></p>

<p>Where <code>time</code> is the interval between the getwork requests and <code>noncemax</code> is the size of nonce field (2^32). However, this assumes no time delay due to the network lag and so forth, so it's an ideal scenario. Moreover, some miners discard unfinished work after submitting a share, so it would appear they are doing more work in your configuration than they actually are.</p>

<p>If you intend on using <a href="https://en.bitcoin.it/wiki/Getwork#Extensions" rel="nofollow">getwork extensions</a>, specifically <a href="https://en.bitcoin.it/wiki/Getwork#noncerange" rel="nofollow">noncerange</a> and <a href="https://en.bitcoin.it/wiki/Getwork#rollntime" rel="nofollow">rollntime</a>, you could calculate the hashrate more accurately. Noncerange would change your <code>noncemax</code> to whatever size you set, and rollntime would allow you to measure time intervals greater than one second. However, <a href="https://en.bitcoin.it/wiki/Getwork_support" rel="nofollow">not all miners support the extensions</a>.</p>

CC BY-SA 3.0
2015-06-16T08:22:29.220Z
Getwork is old. Could you discuss [getblocktemplate](https://en.bitcoin.it/wiki/Getblocktemplate)? thanks
Geremia
CC BY-SA 3.0
2015-06-16T17:54:24.910Z
@Geremia Create a separate question and someone might elaborate.
ThePiachu
CC BY-SA 3.0
2012-04-15T14:26:02.553Z
Thank you for this explanation. In case anybody wonders about the same thing: in my local setup your formula results in hashrates which are consistently about 36% above the values I get displayed by cgminer. I am looking at various hashrates, ranging from (according to cgminer) about 600Mh/s at 5.23 seconds between getworks to 1700Mh/s at 1.86 seconds between getworks. I'm assuming this is due to the effects you mentioned. Thanks again!
Noah
CC BY-SA 3.0
2012-04-15T12:39:04.800Z
2012-04-15T12:49:53.490Z
2012-04-15T12:49:53.490Z
ThePiachu
<p>In a setup where a standard bitcoind serves full difficulty targets to some mining nodes, how can I calculate the hashrate of a mining node from looking at the rate of getwork requests? Does this depend on the used mining program or the used mining extensions?</p>

CC BY-SA 3.0
2012-04-15T12:48:02.107Z
Why would you want to do something like that? If you want to minimize the amount of shares sent, you can just increase the difficulty by some factor, rather than giving full difficulty and using getworks as a measurement. Your solution could potentially lead to exploits where the miner would send more getwork requests while not processing them all.
ThePiachu
CC BY-SA 3.0
2012-04-15T13:06:04.010Z
Thank you for pointing that out. I understand that this question is of little importance for practical implementations. It does however help to better understand the getwork mechanism. I was experimenting with a local setup and was wondering about the exact relationship.
Noah
<hash><difficulty><getwork>
How does the rate of getwork requests correlate with the hashrate of a miner?
Noah
# How does the rate of getwork requests correlate with the hashrate of a miner?

(Asked by: username_0 on 2012-04-15)

In a setup where a standard bitcoind serves full difficulty targets to some mining nodes, how can I calculate the hashrate of a mining node from looking at the rate of getwork requests? Does this depend on the used mining program or the used mining extensions?

**Tags:** hash, difficulty, getwork

> **Comments:**
> **username_1**: Why would you want to do something like that? If you want to minimize the amount of shares sent, you can just increase the difficulty by some factor, rather than giving full difficulty and using getworks as a measurement. Your solution could potentially lead to exploits where the miner would send more getwork requests while not processing them all.  
> **username_0**: Thank you for pointing that out. I understand that this question is of little importance for practical implementations. It does however help to better understand the getwork mechanism. I was experimenting with a local setup and was wondering about the exact relationship.  

---

## 1 answers

### Answer by username_1 on 2012-04-15. Score: 3 | Accepted answer

The standard getwork protocol forces the miner to send a new request every second. This means that if a miner takes longer than 1 second to check all nonces in a given getwork (2^32), it will be making a new request before it checks all values in a given request, thus giving you 1 getwork request per second regardless of the hashrate.

If the miner can solve the getwork faster than that, it would be making requests more often. In theory, you could use this formula to calculate the hashrate:

`Hashrate = noncemax/time`

Where `time` is the interval between the getwork requests and `noncemax` is the size of nonce field (2^32). However, this assumes no time delay due to the network lag and so forth, so it's an ideal scenario. Moreover, some miners discard unfinished work after submitting a share, so it would appear they are doing more work in your configuration than they actually are.

If you intend on using [getwork extensions](https://en.bitcoin.it/wiki/Getwork#Extensions), specifically [noncerange](https://en.bitcoin.it/wiki/Getwork#noncerange) and [rollntime](https://en.bitcoin.it/wiki/Getwork#rollntime), you could calculate the hashrate more accurately. Noncerange would change your `noncemax` to whatever size you set, and rollntime would allow you to measure time intervals greater than one second. However, [not all miners support the extensions](https://en.bitcoin.it/wiki/Getwork_support).

> **Comments:**
> **username_0**: Thank you for this explanation. In case anybody wonders about the same thing: in my local setup your formula results in hashrates which are consistently about 36% above the values I get displayed by cgminer. I am looking at various hashrates, ranging from (according to cgminer) about 600Mh/s at 5.23 seconds between getworks to 1700Mh/s at 1.86 seconds between getworks. I'm assuming this is due to the effects you mentioned. Thanks again!  
> **username_2**: Getwork is old. Could you discuss [getblocktemplate](https://en.bitcoin.it/wiki/Getblocktemplate)? thanks  
> **username_1**: @username_2 Create a separate question and someone might elaborate.  

---

