Quote from: Wolf0 on March 19, 2016, 08:46:22 PM

Quote from: sp_ on March 19, 2016, 08:40:38 PM

I can teach you why the kernal is displaying low numbers for low difficulty shares. (and for single cards with a low hashrate)

Take a look at at
https://github.com/tpruvot/ccminer/blob/windows/Algo256/decred.cu

and line 259

      if (h[7] == 0 && cuda_swab32(h[6]) <= highTarget) {

We don't care about the 4 first bytes of the hash and assume they are 0. This is to spead up the search.


Here is a found decred block:(hash)

0000000000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c

0000000 000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c

but when a pool asks for a low difficulty share
f.eks find a number that is less than this:
00000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffff
We are not submitting the shares that have anything else than 00 in the low byte of the first 32 bits. (why should we when we know that the solution doesn't give a block)

If I mod the kernal to search the top 32bits only (h[7]) <= Target the mining software will work exellent at low difficulty, but not so good on higher diff.. We are searching for blocks with 14 leading zero's So I believe the current kernal is good, and the pools are fucked..

Why should we when we know it doesn't give a block? BECAUSE POOLS WORK THAT WAY, DUDE. Not submitting those is literally burning cash. The problem isn't the pools, it's you.

He have fixed it in the opencl version..

With a nice comment

   /* Debug code to help you assess the correctness
    * of your hashing function in case someone decides
    * to try to optimize.
   if (!((pre7 ^ V7 ^ VF) & 0xFFFF0000)) {

https://github.com/tpruvot/sgminer/commit/d78cfbbc77df7a0d2b8c87168a4750e4eb8830a4