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

Thank you so much! This miner gets me about 540 sol/s compared to about 400 sol/s with ccminer 2.2.4

One question to dev :
When i started bminer, the CPU load goes up to 100 for one minute.
It's not a big deal but other miner do not act like this.
Any idea why ? Is it something you can work on ?

Usually miner software products are referring to first card as GPU0. If you see only 3 cards in the console window, make sure your drivers are detecting all cards. You may need to check your config too. Sometimes, we make mistakes by missing easy steps.

Hi, is it  tested & supported  with Ethos now ?

thxs
g.

I have 4 GTX 1080TIs running. I'm completely new to mining, so is it normal, that Bminer displays GPU1, GPU2 and GPU3 in the console window with sol/s increasingly, but doesn't show GPU4? After GPU3 total sol/s is displayed and a new job is received.

As i'm away from the minee, I can't upload a screenshot, sorry.

-devices option will do here.

For example, you can add -devices 0,2,3 at the end of your bat/sh file.

Then bminer will start on GPU 0, 2, and 3.

Help please can you share some command that should i need to add to choose only selected cards to run with bminer.. because i wanted to run other cards in other algo like daggerhashimoto. .or neoscrypt because the other card is not profitable in zcash mining so i need a sample batch file that could run only selected cards to mine zcash..  Thanks in advance..

I have tested it along with DSTM on miningspeed.
Unfortunately, there is no way to tell with the graph if there is an issue or not.
Only way to show the profitability is to have two adresses for payment.
So far i haven't seen a problem.

PLS help me.

I will investigate randomizing nonces in future. I want to say that randomizing nonces is not as simple as it seems. For optimization, a lot of nonce bits have to be zero. This leaves a very tight nonce range to play with. Bminer also needs to allocate nonce bits carefully for each device. Bminer has to be careful here otherwise different devices may start working on overlapping nonces.

I confirm you that -nofee option will roughly slow down the miner by 3.5-4%, so you should get 2% less (because no 2% devfee) than normal. If you do not observe any difference, then it is probably a sign that your testing setup is not accurate enough. Maybe you need to run it longer or with more machines.

I've been running two tests for a week each, on nanopool.
First with Bminer and then with DSTM, and a few hours ago I switched to excavator 1.4.4a, and I'll run that till next Sunday to compare.

I completely ignored miner/pool stats for Sols, and instead focused on Shares and Payments as reported by nanopool.
Since they are paying me for my shares, I have to accept that their numbers are what matters.

Now, I only have a single Asus 1070, not OC'd nor undervolted or any of that fancy stuff, and it's in a regular gaming rig. Now, I didn't (rarely do) play any games during this period, and my box is on and mines 24/7, no matter what I do. It's an i7-6700K, 32 GB RAM, with SSDs. Now, I said no gaming, but I use it every day for a couple of hours, surfing and what-not, including watching movies with Kodi, streaming 720p/1080p content from NAS over local Gbit network. My external network is 1000/100 Mbit and rock solid.

Neither of the miners have caused any troubles for my machine, and I've only noticed that DSTM needed to restart itself a bunch of times during the week. If I remember correctly, Bminer ran without any problems. I rarely restart my computer, but it happens. Same with the miners. If they were ever closed, it was only for a few minutes during the entire week.

My conclusion?
Well, darn near identical results, with a slight edge for DSTM.
Initially, I ran Bminer with devfee and the later days with the -nofee option. I never noticed any difference in Sols, and don't know if it ever affected shares/payments.


Stats in a shared Google Sheets here .

Next week, I'll add numbers for excavtor.

AGAIN AFTER 45 PAGES WE STILL SAY

for all new miner DON'T USE THIS SHIT , STAY AWAY !!

I think % is special in windows batch files and I had to double them up.  This is working for me on windows with nanopool:

Not idealistic at all. It's the required healthy pressure on developers to adopt recommended practices. It happens all the time in various forms. If it hadn't happened then we'd still be using ADA, Fortran and the likes. Bad practices need to go ... encourage developers to write proper stuff, don't encourage them to stay lazy.

For the purposes of closing off the public convo here, we'll just have to agree to disagree then! We simply have different approaches to the same problem. I see your view on this as idealistic; trying to force miners to do things the way you believe is right (regardless of how much better it is) is unrealistic. I choose to approach it from what I see is a more practical vector. But, as you say: sharerate/hashrate measurement is possible either way, and seems to be the goal for many in here.

As I mentioned, this is a borrowed idea, and pseudo-standard in ALL proxies I came across (that I chose to spend time interpreting code on, that is). More importantly, I've confirmed this this approach works with my proxy with both bminer and dstm.

Will msg via PM now. If anyone else on the thread is interested in talking about stratum protocol, please PM me. Now back to your regularly scheduled bminer banter...

@wetblanket, I missed the nonce1 from zpool - to me it looked like the session_id rather than nonce1. However, appending to the nonce1 and prepending to the nonce2 as you previously explained just doesn't work (and can't work). I tried it. Let's continue this on PM.

p.s. of course it's easier done in the miner, and should be done in the miner. Your points are valid, but they perpetuate the problem! It's the miners who should comply first with good practice, and we should encourage, if not coerce, them to ... it's also easier (1 line of code to randomize the seed, rather than hefty work to work around the problem). For anything involving probabilistic approaches, always randomize seeds; in the case of miners, it's pretty idiotic not to because of exactly this proxy problem and duplicate shares.

I was able to get it to work with Nanopool by setting a password instead of an email.

Any statum-like protocol requires sending a nonce1, as miners require it; it's their unique pool-designated nonce-space in which to generate solutions and this prevents duplicates at the pool - so yes, zpool must send it:


"810092d3" above is the nonce1. What equihash does NOT send (unlike other stratum-like protocols) is the nonce2_size (usually about 4), which indicates the size of the nonce2 solution the pool is expecting to receive in a "mining.submit" share.

Equihash takes a different approach, internally defining the total nonce size to be 32 bytes long (much bigger than other algos), so the miner (and also any proxy!) can calculate the length of the nonce2 it needs to generate to satisfy a total length of 32. So: 32 - len(nonce1) ==


I disagree that it's easier done in the miner, but this is mostly a matter of perspective:

• My previous point about not being able to control/patch all miners means that if you take the approach of dictating to miners that they have to change their code to your way of thinking simply means that your proxy will not be compatible with miners that choose not to do so. Patching the code isn't the hard part; it's ensuring all miners do so.
• You certainly CAN patch miners to generate nonce2 values randomly; however given the same nonce1, there is still a small chance two rigs will randomly generate the same nonce2 value. This would still result in a duplicate share. The possibility is admittedly incredibly remote, but the chance is still there.

From a different point of view: a miner cannot control what other miners are doing; only the source of information can do that. In a pool -> miner relationship, the pool fills that role. If a proxy is put in the middle, then the proxy must serve that role for its connected miners.

This is literally the canonical proxy example, which does exactly what I'm saying. I'm not inventing this approach, I'm just describing something that already works and all but guarantees the avoidance of duplicate shares.