Quote from: Keko Fdez on March 24, 2018, 10:29:55 AM

Quote from: realbminer on March 23, 2018, 10:54:58 AM

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

Thank you for your feedback.

1. I will keep improving the stability of bminer. Could you share some log/screenshot to me so that I can understand why bminer restarted in your rig? Thank you.

2. Besides 2% devfee, some shares will get lost due to network communications and job switches. This is why such hashrate gaps exist for all miners. In 6.0, we have changed the way we count sol/s to exclude some of the stale solutions, so that the hashrate statistic is more accurate now.
In practice, it is not possible for any miner to quantify potential network loss and therefore gaps will always exist.
See https://www.bminer.me/faq/#why-the-reported-hashrate-of-bminer-is-higher-than-the-reported-hashrate-from-mining-pools

3. Bminer does not use CPU to mine anything. In bminer 6.0, I believe bminer consumes similar or less CPU than other miners. Bminer does use CPU to perform some pre-processing and post-processing to support GPU computations. Those CPU tasks are light but time-critical. It means that if it does not finish in time then GPU will wait for CPU and wasting computation cycle of GPU. Enforcing power management cap on the whole system is not a good idea because windows would insert forced idle bubble in CPU cycle causing potential delays in GPU computations.

With bminer 6.0, even without any such cap, the CPU usage would stay below 60% for just 6 GPU (unless you are using a very old CPU).

4. Yes, I am open to this idea. But simply counting the number of shares will just confuse people due to potentially different difficulties of shares. Once I figured out a right way to implement this, I will do it.

5. The id after the share message is, in fact, the message communication id. In ZCash stratum, the #0 message is the login, the #1 is nonce subscription, and the #2 is mining notify subscription. So the first share starts at #3. I can make the counter starting at 1 if all of you guys think it looks better.