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

[threeflappp]

What you did is flawed on multiple levels. You did two tests consecutively, and then also looked at the payout. The difficulty of the algo you mine will have changed in the meantime, making the 2nd run easier/harder to mine, but never the same. You also looked at payouts but never mention what currency, because if it is anything other than the coin you mine, and it looks like you are talking about BTC, then the market will also have fluctuated the price by the time of the 2nd run. Shortly put: don't trust what you just did ...

It was Zclassic. I infered difficulty from estimated rewards on Zclassic which shows how much of that specific coin you may get based on the difficulty at the time. Yes, I understand this is estimated. Difficulty goes up and down all day so you take a 24 hour average. During the test, estimated rewards differences were less than 5%.

Also, no one has yet to dispute my other point about hash rate when dev fee is on/off. There is no difference between the two option in hash rate shown and actual rewards despite documentation that optimizations are disabled.

Someone else please try disabling devfee.

[1713582204]

1713582204

[1713582204]

1713582204

[1713582204]

1713582204

[1713582204]

1713582204

[1713582204]

1713582204

[MiningTaken]

@RealBminer :
I noticed the increase Hashrate of using Bminer (521,67 Sol/s) instead of DSTM 0.58 (505 Sol/s) on my GTX 1070 Ti. That's very good. Good job!
But I also noticed that Accepted shares per minutes of DSTM is higher than of Bminer.
Could you kindly explain what does it mean?
Which impact more on Profit : Better Hashrate or better Accepted shares ?
Thank you.

[Andrey09]

And dstm has lowest rejected shares than bminer. (on same pool and same hardware)

Could you add in telemetry page reject statistic per card, how much each card accept shares and how much reject ?

[ZenFr]

@RealBminer :
I noticed the increase Hashrate of using Bminer (521,67 Sol/s) instead of DSTM 0.58 (505 Sol/s) on my GTX 1070 Ti. That's very good. Good job!
But I also noticed that Accepted shares per minutes of DSTM is higher than of Bminer.
Could you kindly explain what does it mean?
Which impact more on Profit : Better Hashrate or better Accepted shares ?
Thank you.

I don"t know what is the issue with BMiner, but we are many people to see what you wrote (on same pool and same hardware) :
 1 - the miner hashrate is bigger with BMiner than DSTM, but the number of share is bigger with DSTM than BMiner : in my case, DSTM is more profitable than BMiner
 2 - dstm has lowest rejected shares than bminer.

[MiningTaken]

[/quote]
I don"t know what is the issue with BMiner, but we are many people to see what you wrote (on same pool and same hardware) :
 1 - the miner hashrate is bigger with BMiner than DSTM, but the number of share is bigger with DSTM than BMiner : in my case, DSTM is more profitable than BMiner
 2 - dstm has lowest rejected shares than bminer.
[/quote]

1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!

[threeflappp]

1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!

In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?

[MiningTaken]

1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!

In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?

In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)

[threeflappp]

1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!

In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?

In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)

I think you and the other guy is misunderstanding me. I don't mind devfee at all. I'm using DSTM where you can't turn off devfee.

I'm asking people to try out the no devfee option to see if they see any change in hashrate/share/payout.

[chuckn3v3rsold]

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!

[realbminer]

1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!

In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?

In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)

It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!

[realbminer]

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!

This is expected -- The Linux version does not have this issue.

The reason is that I have to insert some delays to work around the bugs in the NVIDIA drivers under Windows. Without the delay the drivers will just hang. 

However, I think there might be some opportunities to make it work better. Will look into it.

[gettilee]

It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!

thanks for the explanation and i think it would be great if you took the time to write out how it all works and put it in your first post so everyone understands it when they download it.

i would love to switch over to bminer full time and ditch dstm, but i have a few concerns first:

1) accepted/invalid share/rejected share clarification would be great. confirmation if sending invalid shares penalizes, thats a big deal. test on flypool since its the largest?

2) if the total reported hashrate from bminer includes the dev fee, perhaps adding an addition line of just the dev fee hashrate so we aren't seeing as big of dependencies between miner and pool hashrate.

3) you still haven't detailed why Bminer contacting 104.31.68.221:443/104.31.69.221:443 regularly. runtime and licensing information is too vague to mean anything to us.

[chuckn3v3rsold]

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!

This is expected -- The Linux version does not have this issue.

The reason is that I have to insert some delays to work around the bugs in the NVIDIA drivers under Windows. Without the delay the drivers will just hang. 

However, I think there might be some opportunities to make it work better. Will look into it.

Thanks for your answer and explanation.

[zerimis]

Have just started trying out bminer and have found it definitely squeezes out some additional hashrate.

One request would be to honor CUDA_VISIBLE_DEVICES, or to allow "-devices" to take the GPU's UUID.

I use some scripts to manage the miner processes and have mappings to what miners should be running on which GPUs. One annoyances with the index based settings of "0,1,2" is that the ID used does not match the ID from nvidia-smi. I found this the hard way and it isn't well documented. I could find a simple way to find out what the order was, but did find that CUDA_VISIBLE_DEVICES supports a comma-separated list of the GPU's UUID, so that was my solution.

With bminer, I had the env var set to the UUIDs, but it was trying to use all GPUs. When I used -devices, it was the same thing of IDs not matching the ordering in nvidia-smi or the order the NVML API returns them in.

Thanks!

[MiningTaken]

1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!

In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?

In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)

It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!

Thank you very much for your answer, RealBminer. :-)
I think all of us would really appreciate your hard work and your honest & straightforward answers.

If you don't mind, please do spend some time to write out how the whole thing works.
And also, there are some requests on more detailed information reported via the API (127.0.0.1:1880), like Net Hashrate, Miner's Uptime, etc.
It would be great if you would do that!
Thank you again.

[CryptoWatcher420]

1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!

In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?

In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)

It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!

I can call bullshit on that number 4 comment you aren't here for us, if you were how bout you lower your dev to to say 1 percent or maybe .5 percent, youll get more people to use your program to make up for the difference, your not here to really help us as much as you are helping yourself, you devs do nothing but cheat us miners and spit bullshit. yall don't update stuff hardly even enough to merit what we PAY YOU each month PER rig, you are no different than claymore, yall are only here to benefit yourself, numbers speak for themselves man. cheating does go far and you and every other dev is proof of that

[apiontek]

New 5.3.0 still won't work on my two Windows 10 machines with GTX 1070s. No output, regardless of option provided or no option provided. And the lack of debugging info, advice, attention by the dev speaks volumes.

I don't really care anymore. It reports higher hashrates on my Linux machines, but given other people's experiences, I'm suspicious, so I won't use it there.

Amusingly, it does run on Win10 on an old laptop I have that's powering a GTX 970 via external expresscard adapter. But it reports a lower hashrate than dstm so.... there's no point there.

[dkmontague]

On my 6 * 1080Ti, everything is the same( 240h/s). On dstm's ZCash 05.8 and ewbf miner 0.3.4b everything is fine.
With similar settings. In the furnace this miner.

Your issue appears identical to mine... have you found a solution?

[cryptoyes]

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!

This is expected -- The Linux version does not have this issue.

The reason is that I have to insert some delays to work around the bugs in the NVIDIA drivers under Windows. Without the delay the drivers will just hang.  

However, I think there might be some opportunities to make it work better. Will look into it.

It most certainly does too under Linux. 40 seconds driver init time for 13 cards under 384.xx drivers, and a whopping 80-90 seconds for the same 13 cards under 387.xx and 390.xx drivers ... Nvidia is making it worse and worse. I fu**ing hate working with Nvidia cards, especially under Linux. Fu**ing bastards and their shitty idiotic drivers and software (that also require you to run X in order to overclock).

If you know of a way to get rid of this long driver init time under Linux, then please, by all means, do share!

[orangesherbet0]

Guys, bminer has been shown to inflate its reported hashrate. In the code (which nobody can see) this is really easy to do - and why wouldn't you inflate it 10% if it meant 10x more people downloading your program (which you make a lot of profit from)?

The problem is, somebody benchmarked it and showed it to be no faster than DSTM ZM, which shows a much lower hashrate.

https://forum.z.cash/t/new-miner-bminer-a-fast-equihash-miner-for-cuda-gpus-5-1-0/26197/12

Please stop spreading this scam miner, and by god don't install it.