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?
-
1Why 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.– ThePiachuCommented Apr 15, 2012 at 12:48
-
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.– NoahCommented Apr 15, 2012 at 13:06
Add a comment
|
1 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, specifically noncerange and 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.
answered Apr 15, 2012 at 12:39
-
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!– NoahCommented Apr 15, 2012 at 14:26
-
-
@Geremia Create a separate question and someone might elaborate. Commented Jun 16, 2015 at 17:54