<p>It's likely your intensity is too high. Usually higher intensity or other settings may look good with higher hashing power, but in truth results in a lot of false positives.</p>

<p>Playing around with the settings till you get the sweet spot is the best practice.</p>

CC BY-SA 3.0
2014-03-07T05:23:19.083Z
2014-03-07T05:23:19.083Z
Thoth
<p>I understand that GPU might have less accurate results of real numbers because speed/performance is the target. But I don't understand why it also occurred in integer numbers.</p>

<p>Taking mining algorithm, scrypt hashing, for example, there are almost integer operations in SHA-256 or PBKDF, such as unsigned integer rotate, shift, add, xor, and bit-select operators. However, it does generate so many false-positive nonces. Everyone can invoke cgminer with arguments <code>-T -D --verbose</code> to see the detail logs. However, cgminer will verify the result via CPU routine again before sending it to mining pool because too many invalid share cgminer will be banned from the pool. Not everyone knows their GPU generates so many false-positive shares because the default log message does not show this.</p>

<p>So, I don't understand that. Is the problem in GPU or in the scrypt OpenCL code?</p>

CC BY-SA 3.0
2014-02-10T15:09:58.810Z
No. You can invoke cgminer with the argument '-T -D --verbose' to see what is going on. I believe hat's not GPU failure because it can continue producing the correct nonce, and the mining pool see the right hash-rate as well.
Of course CPU is super hot because CPU needs to feed data to GPU and keeps verifying all results generated from GPU
jclin
CC BY-SA 3.0
2014-02-10T15:17:42.347Z
I definitely see more errors when I push my cards too close to their limits. I assume it has something to do with hardware errors.
Chris S
CC BY-SA 3.0
2014-02-10T15:27:03.550Z
The issue also can be reproduced when you did not push your cards to their limits, for example, lower intensity. Even you set with proper or lower GPU engine/memory clock rate (I did not overclock the GPU). And this is not HW error in cgminer because you can see many false-positive but with 0 HW errors when you run with `-T -D --verbose`.
jclin
CC BY-SA 3.0
2014-02-10T16:48:14.210Z
I believe this belongs more in Con Kolivas' page as a bug request than here. Anyway, your testing looks interesting - have you tried using an über low intensity? Is this anything to do with the "hardware errors" measure that cgminer does show, or is it something different?
Joe Pineda
CC BY-SA 3.0
2014-02-11T01:03:44.413Z
I'm not sure it is a bug or not. I tune the intensity to lower one, about 13, to avoid hardware errors. But GPU still produces many false-positive nonces under the debug and verbose arguments. However, without those debug arguments, cgminer looks normal. Hashrate is good and WU is good; the hashrate seen by the pool is also good; the earned coins are much the same as the daily estimated (if difficulty does not change a lot)
jclin
<litecoin><cgminer><scrypt><mining-pool-shares>
Why GPU (cgminer) scrypt mining generates so many false-positive nonces?
jclin
# Why GPU (cgminer) scrypt mining generates so many false-positive nonces?

(Asked by: username_0 on 2014-02-10)

I understand that GPU might have less accurate results of real numbers because speed/performance is the target. But I don't understand why it also occurred in integer numbers.

Taking mining algorithm, scrypt hashing, for example, there are almost integer operations in SHA-256 or PBKDF, such as unsigned integer rotate, shift, add, xor, and bit-select operators. However, it does generate so many false-positive nonces. Everyone can invoke cgminer with arguments `-T -D --verbose` to see the detail logs. However, cgminer will verify the result via CPU routine again before sending it to mining pool because too many invalid share cgminer will be banned from the pool. Not everyone knows their GPU generates so many false-positive shares because the default log message does not show this.

So, I don't understand that. Is the problem in GPU or in the scrypt OpenCL code?

**Tags:** litecoin, cgminer, scrypt, mining-pool-shares

> **Comments:**
> **username_0**: No. You can invoke cgminer with the argument '-T -D --verbose' to see what is going on. I believe hat's not GPU failure because it can continue producing the correct nonce, and the mining pool see the right hash-rate as well. Of course CPU is super hot because CPU needs to feed data to GPU and keeps verifying all results generated from GPU  
> **username_1**: I definitely see more errors when I push my cards too close to their limits. I assume it has something to do with hardware errors.  
> **username_0**: The issue also can be reproduced when you did not push your cards to their limits, for example, lower intensity. Even you set with proper or lower GPU engine/memory clock rate (I did not overclock the GPU). And this is not HW error in cgminer because you can see many false-positive but with 0 HW errors when you run with `-T -D --verbose`.  
> **username_2**: I believe this belongs more in Con Kolivas' page as a bug request than here. Anyway, your testing looks interesting - have you tried using an über low intensity? Is this anything to do with the "hardware errors" measure that cgminer does show, or is it something different?  
> **username_0**: I'm not sure it is a bug or not. I tune the intensity to lower one, about 13, to avoid hardware errors. But GPU still produces many false-positive nonces under the debug and verbose arguments. However, without those debug arguments, cgminer looks normal. Hashrate is good and WU is good; the hashrate seen by the pool is also good; the earned coins are much the same as the daily estimated (if difficulty does not change a lot)  

---

## 1 answers

### Answer by username_3 on 2014-03-07. Score: 1

It's likely your intensity is too high. Usually higher intensity or other settings may look good with higher hashing power, but in truth results in a lot of false positives.

Playing around with the settings till you get the sweet spot is the best practice.


---

