Im using windows 10 on my machines.
Gonna move over my headless systems to ubuntu. Also im no linux guru so yeah.....
Also i have been running almost 24 hours now i belive this latest miner and it seems to me it works pretty nice.
I have 3.99% rejected shares for bbp.
Perhaps i can get less rejected shares by changing difficulty to 256 for bbp ?
Oh ok, good to know that you have a headless linux to test on also.
Yes, please let me make a post first for the next release so you can test with the newest version as Im seeing now that monero actually doesnt recommend people to debug in MSVS as some devs are complaining about crashes, so Im building a windows version now in mingw64, to see if the problem the whole time has been the way VS2017 compiles the code. I also see XMRig no longer supports VS.
Uh, as far as rejects, I don't think we have to worry much as let me explain something on those - and since we are such as "niche" this is actually slightly different info than POBH, or RX in prod. Since bbp-rx solves for an algorithm, our stales mean any hash that was submitted after the block changes (or a client really was solving for the wrong prior block hash).
So, in our case our hashes will really be minimized when the difficulty increases.
Another words: With tiny diff (we have a .005 diff in testnet), if any miners share solves the block, there is a very high propensity for stale shares over the next 30 seconds (while the clients abort the current shares and get new ones).
However, when diff is say 10 in prod, since we do support multiple solutions per round (this is in contrast to the way bbp in prod works, which will be a big pro). Another words, you can have 20 threads running, and if 10 solve shares, they will all be accepted (because all 10 had a chance to solve that block for that round).
So basically, its more on my end - I will try increasing the pools latency for block scanning in testnet. But in testnet, if we can get diff to increase, stale shares should drop even more to a miniscule number (ie < 1%).