Hashing is random, so you might have just gotten lucky.
Do a reset and let it run for another day. If you're still getting persistent positive luck, then there's probably something wonky in the code.
Topic: Estimated Mining Rate Exceeds Measured Rate? (Read 1234 times)
I'm hoping someone here can help me decipher this mystery. poclbm displays two hashing rates when it is running. The real hashing rate, and the estimated hashing rate:
The first rate is calculated directly from the number of hashes the GPU has processed. So it should be the most accurate number.
The second number is the estimated hashing rate, and it's calculated from the number of shares poclbm actually submits within a window of time (15 minutes by default). It should not directly reflect the GPU's actual processing speed, but rather it's a good estimate of "all things considered" hashing rate.
I made a small modification to the code for that second value:
If I use the command line option "-e -1" it will now estimate hashing rate over the entire run-time of poclbm, and all submitted hashes, even rejected ones. I wanted this, so I could be sure that experimental kernels were really producing the expected hashrate. For example, if the kernel or myself screwed up nonce calculations it could end up re-hashing the same nonce, and hence reduce real performance.
The Problem: In the above screenshot, I ran with "-e -1" for a hair under a day now ... and estimated has remained at approximately 363MH/s since last night. That's 9 MH/s (2.5%) more than what should be the most accurate number. Can anyone figure out what might account for this discrepancy?
As far as I can tell, share_count should be accurate; no share should be counted twice.
All the code is here:
https://github.com/progranism/poclbm
And should be up-to-date with m0mchil's code except for my modifications.
The first rate is calculated directly from the number of hashes the GPU has processed. So it should be the most accurate number.
The second number is the estimated hashing rate, and it's calculated from the number of shares poclbm actually submits within a window of time (15 minutes by default). It should not directly reflect the GPU's actual processing speed, but rather it's a good estimate of "all things considered" hashing rate.
I made a small modification to the code for that second value:
Code:
if self.options.estimate == -1:
total_shares = self.share_count[1] + self.share_count[0]
estimated_rate = Decimal(total_shares) * (work.targetQ) / int(now - start_time) / 1000
else:
total_shares = self.share_count[1] + self.share_count[0]
estimated_rate = Decimal(total_shares) * (work.targetQ) / int(now - start_time) / 1000
else:
If I use the command line option "-e -1" it will now estimate hashing rate over the entire run-time of poclbm, and all submitted hashes, even rejected ones. I wanted this, so I could be sure that experimental kernels were really producing the expected hashrate. For example, if the kernel or myself screwed up nonce calculations it could end up re-hashing the same nonce, and hence reduce real performance.
The Problem: In the above screenshot, I ran with "-e -1" for a hair under a day now ... and estimated has remained at approximately 363MH/s since last night. That's 9 MH/s (2.5%) more than what should be the most accurate number. Can anyone figure out what might account for this discrepancy?
As far as I can tell, share_count should be accurate; no share should be counted twice.
All the code is here:
https://github.com/progranism/poclbm
And should be up-to-date with m0mchil's code except for my modifications.
Jump to: