50% of the shares come in with a difficulty between 0.05 and 0.15 at a rate of 10 shares per minute. However, episodically, CPUMiner calculates shares with a difficulty of 10.0 and even 40.0
Shouldn't each share have the same difficulty? 
Topic: How can I get a hashrate from hash-difficulty (Read 58 times)
Essentially, we need the hashrate displayed by the miner's device to match the hashrate we calculate based on the difficulty of the shares (hashes) it submits.
Can't you accomplish that by making the shares small enough, so the miner has multiple shares per reward period? That way you should get a nice average instead of peaks.A real-world example: during local testing with CPUMiner, 50% of the shares come in with a difficulty between 0.05 and 0.15 at a rate of 10 shares per minute. However, episodically, CPUMiner calculates shares with a difficulty of 10.0 and even 40.0 - and this completely skews the hashrate calculation over 10-minute intervals. I've tried trimming extreme values in the calculations, but I still can't achieve acceptable accuracy between the hashrate reported by CPUMiner in its logs and the hashrate we calculate. I'm currently experimenting with different normalization schemes, but haven't found a suitable solution yet. So I thought - maybe someone has a ready-made solution.
Essentially, we need the hashrate displayed by the miner's device to match the hashrate we calculate based on the difficulty of the shares (hashes) it submits.
Can't you accomplish that by making the shares small enough, so the miner has multiple shares per reward period? That way you should get a nice average instead of peaks. Let me start by saying I'm not a Bitcoin miner, but can't you increase the time period over which you calculate the hashrate?
We are developing a mining pool, and it would be beneficial for us to know the hashrate statistics of each worker over a 10-minute period to distribute rewards fairly. Essentially, we need the hashrate displayed by the miner's device to match the hashrate we calculate based on the difficulty of the shares (hashes) it submits.
However, in practice, CPUMiner, for example, finds shares with difficulties ranging from 0.01 to 10.0 within a 10-minute period. As a result, our formula leads to a hashrate that fluctuates wildly (by several times), deviating significantly from the actual hashrate.
Isn't that normal? That's why the network hashrate is an estimate, and the difficulty is only adjusted every 2016 blocks.Quote
Could you suggest a solution or at least point us in the right direction for further investigation?
Let me start by saying I'm not a Bitcoin miner, but can't you increase the time period over which you calculate the hashrate? 
Greetings!
During testing and calculating the hashrate of workers (in some bitcoin-app), we've encountered a challenge:
- The calculated hashrate of miners, based on the difficulty of the shares they submit, differs significantly (by several times) from the actual hashrate of the workers – both for ASICs and CPUMiner.
We calculate the hashrate as follows (this is pseudocode for simplicity):
```
diff = max_target / hash
total_hashes = sum(difficulty * pow(2, 32))
hash_rate = total_hashes / sec
```
Essentially, we determine the number of hashes required to find a hash of the required difficulty (`difficulty * pow(2, 32)`), and then we do this for all hashes found in the last 10 minutes, sum them up, and divide the sum by 600 seconds.
It seems like it should work.
However, in practice, CPUMiner, for example, finds shares with difficulties ranging from 0.01 to 10.0 within a 10-minute period. As a result, our formula leads to a hashrate that fluctuates wildly (by several times), deviating significantly from the actual hashrate.
Have you encountered anything similar? Could you suggest a solution or at least point us in the right direction for further investigation?
Thanks in advance to everyone who participates in this discussion.
During testing and calculating the hashrate of workers (in some bitcoin-app), we've encountered a challenge:
- The calculated hashrate of miners, based on the difficulty of the shares they submit, differs significantly (by several times) from the actual hashrate of the workers – both for ASICs and CPUMiner.
We calculate the hashrate as follows (this is pseudocode for simplicity):
```
diff = max_target / hash
total_hashes = sum(difficulty * pow(2, 32))
hash_rate = total_hashes / sec
```
Essentially, we determine the number of hashes required to find a hash of the required difficulty (`difficulty * pow(2, 32)`), and then we do this for all hashes found in the last 10 minutes, sum them up, and divide the sum by 600 seconds.
It seems like it should work.
However, in practice, CPUMiner, for example, finds shares with difficulties ranging from 0.01 to 10.0 within a 10-minute period. As a result, our formula leads to a hashrate that fluctuates wildly (by several times), deviating significantly from the actual hashrate.
Have you encountered anything similar? Could you suggest a solution or at least point us in the right direction for further investigation?
Thanks in advance to everyone who participates in this discussion.
Jump to: