Actually now I'm pretty convinced that the issue is either with the pool or the miner or both. Bible_pay says that every miner is mining on the same difficulty, that right there leads me to believe that the pool can't keep up with the shares submitted. Of course there is no output to see so you can't tell how many shares you are submitting that are valid or invalid. Then there are these 2 posts:
http://forum.biblepay.org/index.php?topic=17.0http://forum.biblepay.org/index.php?topic=18.0If multiple threads are hashing the same share that would explain why there is such a big difference between local and pool hashrate, and why multiple daemons work best.
Just to reiterate this again:
- All shares issued by the pool are the same difficulty
- HPS2 is supposed to be different than HPS
- HPS2 is based on how many shares you solved in the current round, while HPS is based on your CPU clock hashes per sec.
- The pool is not behind and is able to handle the load (I know because I wrote it, deployed it, and I monitor the performance counters)
You can see clearly that when viewing the leaderboard, the same machines are at the top- and we have a consistent list of users per hashpersec2 reported in the same places. (IE randomness is not a primary factor).
There are certain people here on this thread that are unhappy that lower end processors achieve a higher HPS than their proc. That is a personal problem.
All the code is public domain, you are all free to download it from github and run variations of the miner on your bench if you think there is some inconsistency with your processor.
The KEY ISSUE that some people are not grasping with biblepay is this:
A high percentage of processor power in the biblehash algorithm is going to querying the node vector itself, not wasting CPU cycles on the hashing. So if you want to look at this another way, you are being comepensated 60% for running a node, and the rest for the speed. Im happy we ended up like this as it gives everyone a chance to jump in and receive some BBP.
My main concern is to ensure the algo does not get ported to an ASIC or a GPU. Im busy over in our other forum deploying code to enable governance.
We need to ensure that we can service our 100+ orphans and create a full decentralized IT infrastructure to support the orphans far far into the future.