6.0.0 has released.
- Failover server supports. Supply multiple uris (separated by commas) via the -uri option to enable the failover support.
- A launcher GUI for Windows.
- Reduce reject rate caused by stale shares.
- 0.3-0.5% performance improvement depending on card models.
- Fix inaccurate metrics at the start of Bminer.
- Reduce CPU usage the start of bminer.
- Support miner.reconnect().
- Experimental support for miningrigrentals.
- A new option -no-runtime-info to disable runtime information collection.
Happy mining!
Realbminer some feedback for you.
I have run the miner for 12 hours so far with 6 GTX 1070 Ti, 70% TDP, +200 clock, +700 memory and this is what I have noticed so far:
1. The miner restarted 3 times so far in 12 hours so it seems to have a bit of a stability issue. DSTM barely restarted once in 7 days in a raw. (I do like the watchdog though as don´t have to worry about the miner going down).
2. As many people said, the reported hashrate in the console is higher than the one in the pool. I get an average of 3200 sols/s if we deduct your 2% (that is 64 sols/s) it should be aroud 3136 sols/s on the pool as the real hashrate give or take. The pool so far has only reported that hashrate during a period of 2 to 3 hours though I did mention I have been playing with the CPU energy so might be the reason. I will monitor the next 24/48 hours.
3. You said the CPU uses a lot of resources to start the miner and then it lowers due to initial communication between CPU and GPU, right? After modifying the high performance energy plan on windows 10 (basicly I reduce the maximun CPU consumption from 100% down to 60%) the hashrate on the console went down to 3150/3160 sols/s but didn´t bounce back to 3200 as it should. That brings the next question: Are you mining your dev fee with the CPU?? or are you getting something extra on top of the 2% you already mine? It doesn´t make sense that the hashrate lowers after reducing the CPU as all the work is done by the GPUs.
4. It might be a good idea or not, but I think it will be a bit more transparent if next to the accepted shares, rejected shares you included a new count names Dev Shares then we could keep track and see if it really is a 2% what you are taking away.
Edit: 5. When the miner starts working, the first Accepted share is not number 1 or 0, it is always number 3 so it would be nice if it would start on 1 so the Accepted share count would much the shares. Besides starting with a 3 count difference then it grows more and it is on 13 shares difference now that I do not know wherter you took them as dev fee or where they have gone.
Thanks