** Nomp Pool Admins update **
We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me.
We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me.
Hopefully, rebooting the server (or redis-cli shutdown) reset the stats and the pool payout mechanism. I was the only one mining, so the first block belonged to me anyway... LOL I got three blocks last night, so hopefully those pay out to their respective miners. Lots of changes... but without ABN, the non BBP owners are really hogging all the blocks. Its okay, it is only temporary as PoDC 2.0 comes online.
Re: pool -- I'm beginning to think the threshold to submit an acceptable nonce on the lower end causes more resubmission of the duplicate shares. So, I'll try your minimum of diff 4 and see how it goes.
To erase certain stats:
redis-cli
HGETALL biblepay:stats
hset biblepay:stats validShares 0
hset biblepay:stats invalidShares 0
I don't know about the other keys; this is all Ive changed so far to get it to this point.
I tried redis-cli shutdown and removing /var/lib/dump.rdb instead - Maybe that was a bit harsh but I didn't know how to get rid of the bad pool address error.
Did you notice historical data is not from most recent block height? The numbers are out of order sometimes.
for nomp.biblepay.org 154814 and then it is 154869
I'm going to leave my min diff 0.777 but set the difficulty retarget low so high hashers should move up in difficulty quickly. This way, computers with low power can participate more regularly and be encouraged by accepted shares (yay!!!) realizing that they may get more rejected shares from duplicates.
Code:
"3032": {
"diff": 0.777,
"varDiff": {
"minDiff": 0.777,
"maxDiff": 64,
"targetTime": 90,
"retargetTime": 6,
"variancePercent": 1
}
},
"diff": 0.777,
"varDiff": {
"minDiff": 0.777,
"maxDiff": 64,
"targetTime": 90,
"retargetTime": 6,
"variancePercent": 1
}
},
Well the history doesn't backfill until the block gets confirmed (I believe its the value they use for solved vs. confirmed) - so I think that part is OK.
The page just needs a javascript sort on the block height descending, one of us can add that as a pool issue once we get the github enabled.
Edit: The diff idea is cool, as long as your rejects stay relatively low then thats good.
