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.cuand 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.