[ANN]Bminer: a fast Equihash/Ethash/Cuckaroo29z miner for AMD/NVIDIA GPUs 16.4.9

[anotherwave]

I was very skeptical as well for a long time and then I did a 48hr test on 3 1070's on the same rig with the exact same OC's. One running bminer, bminer -nofee and dstm. So bminer seems to start a little slow but by the end bminer was ahead of dstm by a bit so it seems very comparable if not a little faster but who knows exactly with miner luck and what not.. In the case of 1080ti's i find it runs better than dstm.. Thats what i got from my tests... I still like running dstm on my rigs for stability with a monitoring program keeping a eye on it.  

[ltc_bilic]

@realbminer: Because all the miners control miner/gpu crashes differently I prefer to do my own pool switching in simple loop and task scheduler keeps my gpu healthy. Now here's the problem, according to you're reference guide:

-gpucheck uint   90   The interval in seconds that Bminer polls whether the CUDA devices have hung. Set to 0 to disable the checks.
-max-network-failures   -1   Number of consecutive attempts that Bminer tries to recover from network failures. Set to -1 to keep on recovering.
-watchdog   true   Automatic restart to recover from hung GPUs. Bminer exits itself in case of errors if watchdog is disabled.

In order to achive this,...to control everything our selves,...the following should work:

Code:

-max-network-failures 5 -gpucheck 0 -watchdog=false

But unfortunately it doesn't bminer.exe keeps running even if you kill it manually with admin privileges. I've tested it with 5.2 version, haven't had the time to test 5.3 yet.
Can you please elaborate how to effectively control it our selves. I've tested it on Win 8.1 and Win 10. On ewbf miner --eexit 1 works perfectly.

[MagicSmoker]

I just started a head-to-head comparison of dstm 0.5.8 and bminer 5.3.0 mining ZEN to separate wallet addresses on luckpool.org with each getting a GTX 1080 that were tuned to have matching hashrate on either miner (ie - the hashrate reported by bminer was the same on each card, not that the hashrates for bminer and dstm were the same).

Test started at 6:00AM my time and will run for 24 hours so I can use the average difficulty on minethecoin to evaluate how accurately each miner reports its hashrate and, of course, to see which one comes out on top.

I should note, however, that I had some issues with bminer locking up my computer so hard I had to hit the reset button when I tried to exit it while I was setting up the test; not a promising start, really, but it seems to run okay if left alone.

[DES_MX]

Following this with great enthousiasm
Do keep us posted
What's preliminary assessment?

I just started a head-to-head comparison of dstm 0.5.8 and bminer 5.3.0 mining ZEN to separate wallet addresses on luckpool.org with each getting a GTX 1080 that were tuned to have matching hashrate on either miner (ie - the hashrate reported by bminer was the same on each card, not that the hashrates for bminer and dstm were the same).

Test started at 6:00AM my time and will run for 24 hours so I can use the average difficulty on minethecoin to evaluate how accurately each miner reports its hashrate and, of course, to see which one comes out on top.

I should note, however, that I had some issues with bminer locking up my computer so hard I had to hit the reset button when I tried to exit it while I was setting up the test; not a promising start, really, but it seems to run okay if left alone.

[realbminer]

@realbminer: Because all the miners control miner/gpu crashes differently I prefer to do my own pool switching in simple loop and task scheduler keeps my gpu healthy. Now here's the problem, according to you're reference guide:

-gpucheck uint   90   The interval in seconds that Bminer polls whether the CUDA devices have hung. Set to 0 to disable the checks.
-max-network-failures   -1   Number of consecutive attempts that Bminer tries to recover from network failures. Set to -1 to keep on recovering.
-watchdog   true   Automatic restart to recover from hung GPUs. Bminer exits itself in case of errors if watchdog is disabled.

In order to achive this,...to control everything our selves,...the following should work:

Code:

-max-network-failures 5 -gpucheck 0 -watchdog=false

But unfortunately it doesn't bminer.exe keeps running even if you kill it manually with admin privileges. I've tested it with 5.2 version, haven't had the time to test 5.3 yet.
Can you please elaborate how to effectively control it our selves. I've tested it on Win 8.1 and Win 10. On ewbf miner --eexit 1 works perfectly.

How did you run the bminer? Could you try 5.3 again in command line without uri address to see whether it works?

I have just tested on bminer 5.3 in win 10 cmd using:

Code:

bminer.exe -max-network-failures 5 -gpucheck 0 -watchdog=false

Then I killed bminer with task manager and bminer does not come back.

[MagicSmoker]

Following this with great enthousiasm
Do keep us posted
What's preliminary assessment?

I just started a head-to-head comparison of dstm 0.5.8 and bminer 5.3.0 mining ZEN to separate wallet addresses on luckpool.org with each getting a GTX 1080 that were tuned to have matching hashrate on either miner (ie - the hashrate reported by bminer was the same on each card, not that the hashrates for bminer and dstm were the same).
...

The preliminary assessment is unavailable because the luckpool.org web page won't refresh... I've been mining ZEN on there for a couple of months and this happens quite a bit with them, unfortunately. They do have a fairly large pool and high total hashrate, and have proven to be fair and reliable (at least the pool, if not the website).


UPDATE - okay, the luckpool website is back up (mining was unaffected) and so far, at 5 hours in, bminer is in the lead with 0.0103 ZEN vs. dstm with 0.0094 ZEN.

UPDATE 2 - It's now more or less a statistical tie at the 8h mark with 0.0227 ZEN for bminer and 0.0225 ZEN for dstm. Also, bminer has been consistently claiming a hashrate of 550-555 Sols/s while dstm's hashrate has been bouncing around between 520-535 Sols/s.

[scarey12]

When are you gonna fix e-mail adresses?

I tested and it works for me. Can you take another look at https://www.bminer.me/examples/#escaping-characters-in-the-uri ?

I did it exactly like in the link but nanopool got workerFfoo0gmail.com as worker name...

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

Code:

bminer.exe -uri stratum://ADDRESS.WORKER%%2FEMAIL%%40EMAIL.DOMAIN@zec-us-east1.nanopool.org:6666 -api 127.0.0.1:1880

[MagicSmoker]

Just passed the halfway point in my concurrent comparison of bminer 5.3.0 vs. dstm 0.5.8 and to make extra sure things are as fair as possible I flipped miners and rigs - bminer was on Rig 1 mining to Address 1, now it is on Rig 2 but still mining to Address 1, and vice versa for dstm.

The tally so far at the midpoint is 0.0327 ZEN for bminer and 0.0333 ZEN for dstm; less than a 2% difference, but with the advantage going to dstm now.

Testing will end tomorrow at 6:00AM EST and I will let immature shares settle for at least 1 hour before reporting results; luckpool finds blocks very often and provides an accurate tally of what you will earn for your shares, it just takes a while to move them from the immature column to confirmed, same as any other pool.

UPDATE - I just checked on the rigs and both miners were reporting they were hashing away just fine but the pool said bminer was offline. After restarting bminer the pool shows it back online again but there is a steep dip and rebound in the hashrate graph; earnings were affected as well, with dstm now at 0.0374 ZEN and bminer 0.0356 ZEN, so this wasn't a pool issue. I can't think of a worse failure mode for a miner, really - it was still drawing a huge amount of power and appearing to work, but not actually doing anything useful.

[saydex]

Bminer is a highly optimized Equihash miner that runs on modern NVIDIA GPUs (Maxwell and Pascal, i.e. GPUs that have compute capability 5.0 or above). Bminer

It doesn't work on a docker container. Here is my log:

Code:

docker run --runtime=nvidia --rm -t -i e3aae3e4fa60 bminer -uri <my_uri_here>
[INFO] [2018-02-03T00:01:23Z] Bminer: When Crypto-mining Made Fast (v5.3.0-e337b9a)
[INFO] [2018-02-03T00:01:23Z] Checking updates
[INFO] [2018-02-03T00:01:23Z] Watchdog has started
[INFO] [2018-02-03T00:01:23Z] Starting miner on devices [0]
[INFO] [2018-02-03T00:01:24Z] Connected to XXXXXXXX
[INFO] [2018-02-03T00:01:24Z] Subscribed to stratum server
[INFO] [2018-02-03T00:01:24Z] Set nonce to XXXXXXXX
[INFO] [2018-02-03T00:01:24Z] Authorized
[INFO] [2018-02-03T00:01:24Z] Set target to XXXXXXXX
[INFO] [2018-02-03T00:01:24Z] Starting miner on device 0...
[INFO] [2018-02-03T00:01:24Z] Started miner on device 0
panic: runtime error: index out of range
[WARN] [2018-02-03T00:01:24Z] Miner died! It will be restarted soon...
[INFO] [2018-02-03T00:01:31Z] Bminer: When Crypto-mining Made Fast (v5.3.0-e337b9a)
[INFO] [2018-02-03T00:01:31Z] Watchdog has started
[INFO] [2018-02-03T00:01:31Z] Starting miner on devices [0]
[INFO] [2018-02-03T00:01:32Z] Connected to XXXXXXXX
[INFO] [2018-02-03T00:01:32Z] Subscribed to stratum server
[INFO] [2018-02-03T00:01:32Z] Set nonce to XXXXXXXX
[INFO] [2018-02-03T00:01:32Z] Authorized
[INFO] [2018-02-03T00:01:32Z] Set target to XXXXXXXX
[INFO] [2018-02-03T00:01:32Z] Starting miner on device 0...
[INFO] [2018-02-03T00:01:32Z] Started miner on device 0
panic: runtime error: index out of range
[WARN] [2018-02-03T00:01:32Z] Miner died! It will be restarted soon...

Please, fix the issue!

Tnx a lot!

[TDartDDD]

Just passed the halfway point in my concurrent comparison of bminer 5.3.0 vs. dstm 0.5.8 and to make extra sure things are as fair as possible I flipped miners and rigs - bminer was on Rig 1 mining to Address 1, now it is on Rig 2 but still mining to Address 1, and vice versa for dstm.

The tally so far at the midpoint is 0.0327 ZEN for bminer and 0.0333 ZEN for dstm; less than a 2% difference, but with the advantage going to dstm now.

Testing will end tomorrow at 6:00AM EST and I will let immature shares settle for at least 1 hour before reporting results; luckpool finds blocks very often and provides an accurate tally of what you will earn for your shares, it just takes a while to move them from the immature column to confirmed, same as any other pool.

UPDATE - I just checked on the rigs and both miners were reporting they were hashing away just fine but the pool said bminer was offline. After restarting bminer the pool shows it back online again but there is a steep dip and rebound in the hashrate graph; earnings were affected as well, with dstm now at 0.0374 ZEN and bminer 0.0356 ZEN, so this wasn't a pool issue. I can't think of a worse failure mode for a miner, really - it was still drawing a huge amount of power and appearing to work, but not actually doing anything useful.

Now that's sketchy! Still drawing and hashing away but no output?
Does a program usually still continue to run under full load when it occurs an internal error or is there something else happening here?
I'd like to see what realbminer thinks.

[realbminer]

Just passed the halfway point in my concurrent comparison of bminer 5.3.0 vs. dstm 0.5.8 and to make extra sure things are as fair as possible I flipped miners and rigs - bminer was on Rig 1 mining to Address 1, now it is on Rig 2 but still mining to Address 1, and vice versa for dstm.

The tally so far at the midpoint is 0.0327 ZEN for bminer and 0.0333 ZEN for dstm; less than a 2% difference, but with the advantage going to dstm now.

Testing will end tomorrow at 6:00AM EST and I will let immature shares settle for at least 1 hour before reporting results; luckpool finds blocks very often and provides an accurate tally of what you will earn for your shares, it just takes a while to move them from the immature column to confirmed, same as any other pool.

UPDATE - I just checked on the rigs and both miners were reporting they were hashing away just fine but the pool said bminer was offline. After restarting bminer the pool shows it back online again but there is a steep dip and rebound in the hashrate graph; earnings were affected as well, with dstm now at 0.0374 ZEN and bminer 0.0356 ZEN, so this wasn't a pool issue. I can't think of a worse failure mode for a miner, really - it was still drawing a huge amount of power and appearing to work, but not actually doing anything useful.

Could you share the failure log of Bminer? I would love to take a look.

It seems like a network issue that takes longer than usual to reconnect. Bminer does not shutdown GPU during reconnection, because it takes too long to re-init GPUs via Nvidia driver.

In future releases, I plan to add failover server support. I will also find a way to put GPU at idle states that draw less power during reconnection.

[groove_master]

UPDATE - I just checked on the rigs and both miners were reporting they were hashing away just fine but the pool said bminer was offline. After restarting bminer the pool shows it back online again but there is a steep dip and rebound in the hashrate graph; earnings were affected as well, with dstm now at 0.0374 ZEN and bminer 0.0356 ZEN, so this wasn't a pool issue. I can't think of a worse failure mode for a miner, really - it was still drawing a huge amount of power and appearing to work, but not actually doing anything useful.

Yeah, I had this issue yesterday. Bminer was still mining full speed locked at some task, while the dashboard showed I was offline. Restarted the miner and it's been going strong for 24 hours now. The only problem is that the rewards I'm getting from the btg supernova pool are miniscule. Like 3.5 times lower than what the WTM site estimates.

[realbminer]

Bminer is a highly optimized Equihash miner that runs on modern NVIDIA GPUs (Maxwell and Pascal, i.e. GPUs that have compute capability 5.0 or above). Bminer

It doesn't work on a docker container. Here is my log:

Code:

docker run --runtime=nvidia --rm -t -i e3aae3e4fa60 bminer -uri <my_uri_here>
[INFO] [2018-02-03T00:01:23Z] Bminer: When Crypto-mining Made Fast (v5.3.0-e337b9a)
[INFO] [2018-02-03T00:01:23Z] Checking updates
[INFO] [2018-02-03T00:01:23Z] Watchdog has started
[INFO] [2018-02-03T00:01:23Z] Starting miner on devices [0]
[INFO] [2018-02-03T00:01:24Z] Connected to XXXXXXXX
[INFO] [2018-02-03T00:01:24Z] Subscribed to stratum server
[INFO] [2018-02-03T00:01:24Z] Set nonce to XXXXXXXX
[INFO] [2018-02-03T00:01:24Z] Authorized
[INFO] [2018-02-03T00:01:24Z] Set target to XXXXXXXX
[INFO] [2018-02-03T00:01:24Z] Starting miner on device 0...
[INFO] [2018-02-03T00:01:24Z] Started miner on device 0
panic: runtime error: index out of range
[WARN] [2018-02-03T00:01:24Z] Miner died! It will be restarted soon...
[INFO] [2018-02-03T00:01:31Z] Bminer: When Crypto-mining Made Fast (v5.3.0-e337b9a)
[INFO] [2018-02-03T00:01:31Z] Watchdog has started
[INFO] [2018-02-03T00:01:31Z] Starting miner on devices [0]
[INFO] [2018-02-03T00:01:32Z] Connected to XXXXXXXX
[INFO] [2018-02-03T00:01:32Z] Subscribed to stratum server
[INFO] [2018-02-03T00:01:32Z] Set nonce to XXXXXXXX
[INFO] [2018-02-03T00:01:32Z] Authorized
[INFO] [2018-02-03T00:01:32Z] Set target to XXXXXXXX
[INFO] [2018-02-03T00:01:32Z] Starting miner on device 0...
[INFO] [2018-02-03T00:01:32Z] Started miner on device 0
panic: runtime error: index out of range
[WARN] [2018-02-03T00:01:32Z] Miner died! It will be restarted soon...

Please, fix the issue!

Tnx a lot!

I will take a look and see what I can do

[MagicSmoker]

...
UPDATE - I just checked on the rigs and both miners were reporting they were hashing away just fine but the pool said bminer was offline. After restarting bminer the pool shows it back online again but there is a steep dip and rebound in the hashrate graph; earnings were affected as well, with dstm now at 0.0374 ZEN and bminer 0.0356 ZEN, so this wasn't a pool issue. I can't think of a worse failure mode for a miner, really - it was still drawing a huge amount of power and appearing to work, but not actually doing anything useful.

Could you share the failure log of Bminer? I would love to take a look.

It seems like a network issue that takes longer than usual to reconnect. Bminer does not shutdown GPU during reconnection, because it takes too long to re-init GPUs via Nvidia driver.

In future releases, I plan to add failover server support. I will also find a way to put GPU at idle states that draw less power during reconnection.

What failure log? As far as bminer was concerned it was working just fine. It was claiming to get shares accepted and scrolling back up the console window didn't reveal any issues with the network connection. Besides, I was still able to use the web on both mining rigs the entire time the miner was running so that rules out a connection issue. Very peculiar, really.

[Thuen88]

Something sketchy about this miner.  I change to this from DSTM miner, and now after several days the time between each payments from Suprnova is significantly longer even with 100 more sols.

[MagicSmoker]

The results of the dstm vs. bminer showdown have been postponed for 3+ hours because the luckpool website (not the pool) has been down ever since I woke up around 5:30 AM. I did stop both miners at 6:00AM and both were still mining at that time without issue (though, see my posts above). I'll update this post when luckpool's website comes back online.

UPDATE - luckpool's website is back up and I checked the balances of both miners: 0.0613 ZEN for dstm and 0.0584 for bminer. So bminer got trounced by nearly 5%, but some of that might be due it mysteriously crashing without appearing to have crashed for around 1 hour yesterday evening (which I fortunately caught).

In the interest of fairness and to be extra thorough I decided to do a second round of testing with the same methodology as before: each miner runs on a separate desktop with a single GTX 1080 mining to the same pool but with different payment addresses. I've tweaked the MSI AB profile for both cards so that each miner gives the same hashrate regardless of which card it runs on.

[Thuen88]

Almost obvious this is a scam miner. When adding a nofee option so publicly with no significant drop in hashrate, you know there is something not right about it. Why would anyone pay devfee then ?

[realbminer]

Almost obvious this is a scam miner. When adding a nofee option so publicly with no significant drop in hashrate, you know there is something not right about it. Why would anyone pay devfee then ?

Same as Claymore's ZCash miner, Bminer will show the same hash number if you attempt to remove fee (via nofee option or other means). It slows down internally.

In the nofee option, the miner disables some optimizations which slow down roughly 4%, but the miner will not charge any devfee. So you roughly lose 1.5%-2%, while I lose everything.

[Thuen88]

Okey why do you have that as an option if everyone lose on it ?

[pnpvn]

Can it display the temperature?