Topic: [ANN]Bminer: a fast Equihash/Ethash/Cuckaroo29z miner for AMD/NVIDIA GPUs 16.4.9 - page 110. (Read 148347 times)

Thanks for feedback. Are you mining nicehash by any chance?
The restarts have somehow reduced to 1 per day.

I have now noticed that my rig shows offline on the pool as well as on simplemining monitor console but strangely the system is still drawing +750watts off power during this state, as per my energy meter. Full draw on this rig is - +2150watts. This would mean that my system is in some kind on halt state? Is some watchdog initiating?

After 2 days using Bminer v.6.0.0 I noticed a slight decrease of rejected shares in comparison with previous versions, but still a little more than in DSTM(
And what about the performance? Well, on my system, it is the same as with DSTM - no less but no more as it should be (as it report in console).
In my own opinion maybe Bminer sending more than 2% to developer and that is why my hashrate on the Pool is 5% less than miner report in console. While the DSTM miner, in the same system, give me only 2% less (as it should be).
For now I will stay with Bminer because it is more stable on my rigs, but I hope the Developer will improve his miner in the next update and we all will have a really fastest Cuda miner for Equihash)
  

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.

Can't assist you on how to solve the problem, but can report I am having the same problem or similar problem to yours also on a nine card rig. I am also using smos.

Mine is a 9x 1070ti rig. It took me a while to realise I had a problem. I was not paying attention to the console.

Whats happening with mine is that the rig loads up as normal on smos with the slow start from Bminer, then when all GPUs are running at full speed, GPU 8 starts dropping off slowly, the sol rate eventually drops down to zero, the rig keeps running for a while and but then I start getting the restarts about every 30 minutes or so. When I revert back to Bminer v5.5.0 the problem goes away, the rig runs normally. I tried dialing back the overclock on GPU 8 to see if this was the problem but that didn't work either. So for now just working v5.5.0. on this rig.

Funny thing is I have another 9 card rig with identical setup to the first, same mobo same power supply etc. Except this is a mixed card rig, 6x 1070 and 3x 1070t1 but this rig runs normally on Bminer v6.0.0.

I have a third 6x 1070ti card rig and this runs problem free as well with v6.0.0.

Just go back to v5.5.0 is my fix for the moment anyhow.

real-time multi-pool statistics and excellent coin program statistics for the younger generation and automatically switch to other generations and in algorithmic programs
which can be used to ensure the best profitability.

Can anybody assist with the above

Same here at GTX 1080, can't see any improvements over 5.5 and will not use 6.0 version  .

Nothing really has changed since new update, flypool still shows about 1000 sol less than miner console.

About to run my own test with dstm later tonight. I really want to trust bminer

my post wasn't claiming any kind of test. i simply showed how many invalid shares bminer 6.0 was producing in just a few hours compared to dstm which was  running with considerably less over a longer period of time.

i was curious to see what "improvements" bminer had with this latest build and i don't see any hashrate improvement for 1070ti's nor do i see a drop in invalid shares.

i've ran tests before on bminer vs dstm on the same pool at the same time with the same hardware. bminer has always had more invalid shares than dstm.
bminer also over reports hashrate by 3% on console that is not reflected in the pool. combine that with the private connection...either bminer is lying about the console reported hashrate or that hes taking more than 2% because the pool (flypool for my tests) does not reflect the 3% console gain over dstm.

thanks. made a little script for linux, but's easily adapted to windows.


confirmed working on nanopool.

are you plan to use config file?
failover server supports in line too long
and where i can see failover example (separated by commas not work)?
PS working example (separated by commas, no space)

We have changed the way how we calculate hashrate to provide more accurate counting. Starting from 6.0 and later, we detect and drop stale solutions/shares before we send shares to the pool server. We also deducted those stale solutions from our hashrate statistics. This change has several implications:

a. 6.0 should have significantly lower reject rate.

b. Every time a new job comes in, you may see a small fluctuation of hashrate because some computed solutions become stale due to the new job.

c. 6.0 may show slightly lower sol/s than 5.5 (or similar because of minor optimizations in 6.0), but this is not the fair way to compare between two versions. Those stale shares in 5.5 are counted and submitted, but they will eventually get rejected by pool. It does not contribute to your earning.

Here is example:

-uri stratum://[email protected]@zec-us-east1.nanopool.org:6666 -no-timestamps -api 127.0.0.1:1880

how can i use email on the address.workers name, on nanopool? i need it to set the minimum payout.

i've tried the example on the website but didn't worked.

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

I am not an expert neither pro Bminer, but your test or asumption is vague. You barely ran Bminer for a couple of hours and the comparason is not fair. It should be made with both miners running at the same time in different machines with exacty the same hardware and settings to have exactly the same conditions.

I do agree the invalid share rate is a bit higher. I have just started using Bminer as a try out and I have noticed exactly the same but can´t say is fair either because I am not running both miners at the same time.

With DSTM I use to get 0,2% rejected shares and with Bminer so far is nearly 0,5% but I have only been running it for the past 12 hours and been playing with the windows energy management to cut down the CPU.

This is my performance with 6 GTX 1070 Ti, 70% TDP, +200 clock, +700 memory:


And this is Flypool:


There are more fluctuations with Bminer so far, but as I said I have only used the miner for the past 12 hours and I´ve playing with the CPU energy to cut down so more Watts so It will need another 24 to 48 hours to be stable on the pool. I´ll post again the results in 24 hours

switched from dstm 0.6 to bminer 6.0 to see if there was any performance gains with the bminer update

there was NOT any increased hashrate on 1070ti's and the invalid shares improvement in the changelog was not decreased.

the increase in invalid shares from dstm to bminer is pretty big.

https://i.imgur.com/6o4tV7T.png

This is how my hashrate changed with new 6.0 version, it swings much more now:

https://s14.postimg.org/a37usprsh/bminer.jpg


https://s14.postimg.org/a37usprsh/bminer.jpg

That's more of a networking/firewall problem to solve - nothing related to bminer. It's completely dependent on your networking setup (LAN, DNS, WAN, etc). Too many variables to solve via a forum post...