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

MagicSmoker

full member

Activity: 420

Merit: 184

Quote from: realbminer on February 02, 2018, 10:25:14 PM

Quote from: MagicSmoker on February 02, 2018, 06:23:02 PM

...
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.

realbminer

member

Activity: 461

Merit: 49

Quote from: saydex on February 02, 2018, 07:47:45 PM

Quote from: realbminer on December 04, 2017, 11:20:43 AM

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 
[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

groove_master

newbie

Activity: 56

Merit: 0

Quote from: MagicSmoker on February 02, 2018, 06:23:02 PM

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

member

Activity: 461

Merit: 49

Quote from: MagicSmoker on February 02, 2018, 06:23:02 PM

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.

TDartDDD

newbie

Activity: 11

Merit: 0

Quote from: MagicSmoker on February 02, 2018, 06:23:02 PM

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.

saydex

newbie

Activity: 1

Merit: 0

Quote from: realbminer on December 04, 2017, 11:20:43 AM

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 
[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!

MagicSmoker

full member

Activity: 420

Merit: 184

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.

scarey12

newbie

Activity: 3

Merit: 0

Quote

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%%[email protected]:6666 -api 127.0.0.1:1880

MagicSmoker

full member

Activity: 420

Merit: 184

Quote from: DES_MX on February 02, 2018, 08:10:15 AM

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

Quote from: MagicSmoker on February 02, 2018, 07:39:56 AM

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.

realbminer

member

Activity: 461

Merit: 49

Quote from: ltc_bilic on February 02, 2018, 06:55:01 AM

@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:

Quote

-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.

DES_MX

member

Activity: 216

Merit: 13

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

Quote from: MagicSmoker on February 02, 2018, 07:39:56 AM

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.

MagicSmoker

full member

Activity: 420

Merit: 184

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.

ltc_bilic

member

Activity: 130

Merit: 10

@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:

Quote

-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.

anotherwave

newbie

Activity: 39

Merit: 0

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.

orangesherbet0

newbie

Activity: 4

Merit: 0

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.

cryptoyes

member

Activity: 297

Merit: 10

Quote from: realbminer on February 01, 2018, 05:05:39 PM

Quote from: chuckn3v3rsold on February 01, 2018, 02:14:23 PM

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. Sad

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!

dkmontague

newbie

Activity: 51

Merit: 0

Quote from: jewbsv on January 31, 2018, 03:42:07 AM

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?

apiontek

newbie

Activity: 19

Merit: 0

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.

CryptoWatcher420

sr. member

Activity: 462

Merit: 258

Small Time Miner, Rig Builder, Crypto Trader

Quote from: realbminer on February 01, 2018, 05:03:27 PM

Quote from: MiningTaken on February 01, 2018, 11:07:41 AM

Quote from: threeflappp on February 01, 2018, 10:57:43 AM

Quote from: MiningTaken on February 01, 2018, 10:54:56 AM

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

MiningTaken

newbie

Activity: 28

Merit: 0

Quote from: realbminer on February 01, 2018, 05:03:27 PM

Quote from: MiningTaken on February 01, 2018, 11:07:41 AM

Quote from: threeflappp on February 01, 2018, 10:57:43 AM

Quote from: MiningTaken on February 01, 2018, 10:54:56 AM

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.

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