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

[cryptoyes]

Loraine, I think you got your concepts mixed up - payout doesn't ignore rejected shares, and they do affect the comparison of the two miners. You really do care about rejected/invalid/stale shares. Also, you interpret whatever you want but please show all data in the end. Payout is not a relevant metric when comparing miners - sorry. You say bminer has an edge but also think payout is relevant. Well, right now bminer it has worse payout (0.0139+0.00025=0.01415) than dstm (0.01343+0.00971=0.02314) .. that's a huge 63% difference despite having 3.7% less hashrate (5.3 vs 5.5 kh/s).

Use https://uploadfiles.io/ to upload.

Your hping time is very good.

[LoraineLY]

Loraine, I think you got your concepts mixed up - payout doesn't ignore rejected shares. You really do care about rejected/invalid/stale shares.

I think I should rephrase what I meant. You are right, I won't get paid for the rejected shares. What I want to say in my last post is that: the rejected shares will not affect the validity of my testing. It will not skew the results.

logs uploaded:

https://ufile.io/vgf6q

[cryptoyes]

They do affect the validity of your testing if you report payout or total hashrate. You interpret whatever you want but please show all data in the end. Once again, payout is not a relevant metric when comparing miners - sorry. You say bminer has an edge but also think payout is relevant.

Well, right now bminer it has worse payout (0.0139+0.00025=0.01415) than dstm (0.01343+0.00971=0.02314) .. that's a huge 63% difference despite having 3.7% better hashrate (5.5 vs 5.3 kh/s).

[LoraineLY]

Well, right now bminer it has worse payout (0.0139+0.00025=0.01415) than dstm (0.01343+0.00971=0.02314) .. that's a huge 63% difference despite having 3.7% less hashrate (5.3 vs 5.5 kh/s).

This is because the bminer address already got paied once with 0.01012ZEC :

https://zcash.flypool.org/miners/t1LLJPAoYajZjPQggPZcdDpwPont4AoGvfq/payouts

As I said before, this is just for my own testing. It should NOT be interpreted as a general test that can apply to all machines or environments.

The difference between two is still too small to call. Maybe in the next hour or so, the results will flip

[cryptoyes]

I missed that. So it's 0.02427 to 0.2314, i.e. 4.9% better, while having only 3.7% better hashrate (and 0.5% rejected). Makes total sense ... . Luck and PPLNS fuck with payouts. Don't trust payouts.

My interest is whether the rate seen at the pool matches the one reported by the miner. As for comparing the two miners, compare the total number of accepted shares at the pool (that's not equivalent to payout because of PPLNS).

[LoraineLY]

My interest is whether the rate seen at the pool matches the one reported by the miner. As for comparing the two miners, compare the total number of accepted shares at the pool (that's not equivalent to payout because of PPLNS).

Based on the data I have seen so far, none of the two miners matches exactly the pool reported rate. I should see 5.8kH with dstm and close to 6kH with bminer. However, instead, I see 5.4kH and 5.5kH. There is no way to know how different pools/miners count hash rate. Therefore I cannot explain why.

However, the numbers are proportionally in line with each other.
On the pool: bminer is 5.479kH. Dstm is 5.375kH. That's 2% faster.
Miner reports: bminer is 5.99kH, Dstm is 5.810kH. It is close to 3% faster. But consider bminer has 0.5% rejected rate, while dstm has close to 0%. This number makes sense so far.


One thing I observed in the past is that the gap between nanopool number and my ewbf number (I used to run ewbf) is usually closer than the gap between flypool and ewbf. That was another reason why I prefer nano.

[cryptoyes]

The pool has no idea what you're using to mine and it doesn't care. All it knows is that within a certain window of time you submitted N shares and it knows the difficulty of each of those. That's how it computes your hashrate.

It may be that flypool under reports -- I hardly ever used it. I do use ethermine (same pool, but for Ethereum) and that has always been better than nanopool for me. I did a head to head, and ethermine paid better (when comparing pools then yes, I look at payouts).

[cryptoyes]

There is no way to know how different pools/miners count hash rate. Therefore I cannot explain why.

It's quite simple. Effective hashrate = NumShares x ShareDiff / Time ... that's what the pool does. It may add the rejected ones too when displaying hashrate (I don't know for Flypool; Ethermine does not).

Looking at the the bminer1 log, you had 4880 accepted shares, 16000 difficulty, and 27360 total seconds (give or take). That gives 2853 h/s. However, this is the total average over 7.5 hours. Pools show you averages over smaller windows, e.g. 10 minutes, and that will vary a lot more, especially if you have a high share difficulty.

Note that the above hides the miner fee. Bminer does not report the number of shares it computed for the fee when it reports the number of accepted shares, but does include it when it reports the hashrate (I know, it's pretty twisted). Happy to be corrected by @realbminer as I can't know for sure, but the computed hashrate from the shares reported by bminer does not match the hashrate.

[LoraineLY]

It seems that even with 2.8-2.9kH per rig, there is still a big luck factor involved here. The funny thing right now is that bminerr2 now catches up bminerr1 in terms of the total amount of accepted shares (30 more shares now), although bminerr2 should be slightly slower than bminerr1 according to the reported number.

So I have to emphasize again that this is just for my own testing. It should NOT be interpreted as a general test that applies to all.

[LoraineLY]

Looking at the the bminer1 log, you had 4880 accepted shares, 16000 difficulty, and 27360 total seconds (give or take). That gives 2853 h/s. However, this is the total average over 7.5 hours. Pools show you averages over smaller windows, e.g. 10 minutes, and that will vary a lot more, especially if you have a high share difficulty.

That's exactly the frustration I have when I try to look and compare the hash rate. None of the number matches. Bminer tells me it is 3K. Your math shows it is 2.85k, and the flypool shows it is averaged as 2.7k only. I bet if I write a python script to count the "+" sign in dstm log, I will get a different number that does not match as well. Maybe all pools/miners report fraudulent numbers .

That's probably the reason why many people choose to look at payout. At least there is no fake number involved there (In fact, I would love extra payouts for the fake sake  ). Anyway, bminer still gets a little bit more payout, but dstm is trying to catch up.

[cryptoyes]

On ethermine pool I can tell you that it has always under reported my estimated payment and hashrate, but the _actual_ payment matched almost exactly what I expected. It may be that something is off on their side ... but as long as it's off in the same way for all miners then your test is relevant (for which miner's best).

If you want to compare payouts, then leave it longer than 24h (say, 3 days?) and after you stop the rigs, allow for at least 1h more so that the last shares you mined get counted in the last 1h window on Flypool.

I secretly hope bminer is better in the end, simply because dstm on my rigs is reducing hashrate due to too much cpu hogging.

[LoraineLY]

On ethermine pool I can tell you that it has always under reported my estimated payment and hashrate, but the _actual_ payment matched almost exactly what I expected. It may be that something is off on their side ... but as long as it's off in the same way for all miners then your test is relevant (for which miner's best).

If you want to compare payouts, then leave it longer than 24h (say, 3 days?) and after you stop the rigs, allow for at least 1h more so that the last shares you mined get counted in the last 1h window on Flypool.

I secretly hope bminer is better in the end, simply because dstm on my rigs is reducing hashrate due to too much cpu hogging.

Unfortunately, my connection to flypool goes down and all four rigs stop working at the same time around 13:30. Here is the summary of tests I have for the 12 hours, you can check on the page:

dstm: https://zcash.flypool.org/miners/t1SstC4pJy3JtKdqSoFJZk6SUtyznfo1ZB6
https://i.imgur.com/g7agrmg.png

bminer : https://zcash.flypool.org/miners/t1LLJPAoYajZjPQggPZcdDpwPont4AoGvfq
https://i.imgur.com/sjcIHk9.png

              Pool avg. hashrate          Payout
dstm               5.29kH               0.03619ZEC      
bminer            5.48kH               0.03847ZEC

If you are interested in seeing the full running logs, here it is: https://ufile.io/f2906

Note that my experiments should NOT be interpreted as a general experiment that can apply to all situations. The best way to find out which miners work best for you is to try it yourself.

To be honest, I see this as a healthy situation for all of us. As long as the difference between bminer and dstm is small, they will have to play fairly (for example, not raising devfees) and we get more choices.

If I have time, I may run a comparison again maybe on another pool. But I cannot promise because doing this takes a lot of energy.

[MagicSmoker]

Looking at the the bminer1 log, you had 4880 accepted shares, 16000 difficulty, and 27360 total seconds (give or take). That gives 2853 h/s. However, this is the total average over 7.5 hours. Pools show you averages over smaller windows, e.g. 10 minutes, and that will vary a lot more, especially if you have a high share difficulty.

That's exactly the frustration I have when I try to look and compare the hash rate. None of the number matches. Bminer tells me it is 3K. Your math shows it is 2.85k, and the flypool shows it is averaged as 2.7k only. I bet if I write a python script to count the "+" sign in dstm log, I will get a different number that does not match as well. Maybe all pools/miners report fraudulent numbers .

That's probably the reason why many people choose to look at payout. At least there is no fake number involved there (In fact, I would love extra payouts for the fake sake  ). Anyway, bminer still gets a little bit more payout, but dstm is trying to catch up.

Yes, this is precisely why I was looking at payout; it may not be a perfect metric, but average hashrates reported by miner or pool don't seem terribly trustworthy, either. And if luck varies on a per share basis (ie - it takes 5 seconds to solve one share, then 20 seconds to solve another, then 10 seconds for a third, etc.) then counting shares during any given period of time doesn't seem accurate, either as now you are measuring both share luck and hashrate. Frankly, it seems like there is no good metric for evaluating miners...

That said, thanks for taking the time to do this test anyway!

[elgoog]

I tried to run bminer in a docker container(cuda9.0+ubuntu16.04)
bminer stoped with following error.
Bare essentials of package are installed in the docker image.
Is there any required package I should install to run bminer?

Code:

[INFO] [2018-02-07T13:06:41Z] Bminer: When Crypto-mining Made Fast (v5.3.0-e337b9a) 
[INFO] [2018-02-07T13:06:41Z] Watchdog has started                         
[INFO] [2018-02-07T13:06:41Z] Starting miner on devices [0 1]              
[INFO] [2018-02-07T13:06:41Z] Starting miner on device 0...                
[INFO] [2018-02-07T13:06:41Z] Connected to zec-eu1.nanopool.org:6666       
[INFO] [2018-02-07T13:06:41Z] Started miner on device 0                    
[INFO] [2018-02-07T13:06:41Z] Subscribed to stratum server                 
[INFO] [2018-02-07T13:06:41Z] Set nonce to c9b30000000000001409299e5c3a086a 
[INFO] [2018-02-07T13:06:41Z] Set target to 000000000000000000000000000000000000000000000000000000005c8f0200 
[INFO] [2018-02-07T13:06:41Z] Starting miner on device 1...                
[INFO] [2018-02-07T13:06:41Z] Authorized                                   
[INFO] [2018-02-07T13:06:41Z] Received new job 1517939966                  
[INFO] [2018-02-07T13:06:42Z] Started miner on device 1                    
panic: runtime error: index out of range
[WARN] [2018-02-07T13:06:43Z] Miner died! It will be restarted soon...     

I saw same issue in this thread(#645).
Is there any update?

[cryptoyes]

@MagicSmoker ... whatever you say.

@realbminer: I found a quirk.

Code:

[FATA] [2018-02-07T15:12:32+02:00] Irrecoverable errors from watchdog: Client hasn't received Accepted Shares for 5 minutes

When using a single card with high enough difficulty it's possible that a share is not found in a long time. It seems this happens when the pool doesn't send a new share within 5 minutes, but that's not an error, the miner shouldn't disconnect. Could you add an option to tune this time window please? Also, "Client hasn't received Accepted Shares" doesn't sound right ... do you mean "Client hasn't received new jobs from the pool" ?

[MagicSmoker]

@MagicSmoker ... whatever you say.

Lol, just like the assholes in the hsrminer thread that kept saying I was wrong to use payout but never once explained why. You did give a partial explanation, but it seemed to be based on the /belief/ that only share count in a given period of time matters. But then you also said that I need to set difficulty lower for my hashrate because there will be too much variation in the time between shares. Please square that circle, because you can't have both be true.

[cryptoyes]

Lol, just like the assholes in the hsrminer thread that kept saying I was wrong to use payout but never once explained why.
[...]
square that circle, because you can't have both be true.

I have no obligation to do anything (more) for you. You should do some reading before expecting strangers to explain it all to you, but not before you learn some manners. Also consider the following proverb: if you meet an asshole in the morning, then you just met an asshole; if you meet assholes all day, you're the asshole. Take care, kid.

[Scorpio777]

@MagicSmoker ... whatever you say.

@realbminer: I found a quirk.

Code:

[FATA] [2018-02-07T15:12:32+02:00] Irrecoverable errors from watchdog: Client hasn't received Accepted Shares for 5 minutes

When using a single card with high enough difficulty it's possible that a share is not found in a long time. It seems this happens when the pool doesn't send a new share within 5 minutes, but that's not an error, the miner shouldn't disconnect. Could you add an option to tune this time window please?

I agree, it will be very useful. In coinotron pool the shares difficulty is too high and for now i need to add comand "-gpucheck 0" and the miner don't restart every 5min if there are no Accepted Shares for 5 minutes, but sometimes it is very useful to restart miner when there are no Accepted Shares for more than 60min (for example).

[resiva]

On ethermine pool I can tell you that it has always under reported my estimated payment and hashrate, but the _actual_ payment matched almost exactly what I expected. It may be that something is off on their side ... but as long as it's off in the same way for all miners then your test is relevant (for which miner's best).

If you want to compare payouts, then leave it longer than 24h (say, 3 days?) and after you stop the rigs, allow for at least 1h more so that the last shares you mined get counted in the last 1h window on Flypool.

I secretly hope bminer is better in the end, simply because dstm on my rigs is reducing hashrate due to too much cpu hogging.

Unfortunately, my connection to flypool goes down and all four rigs stop working at the same time around 13:30. Here is the summary of tests I have for the 12 hours, you can check on the page:

dstm: https://zcash.flypool.org/miners/t1SstC4pJy3JtKdqSoFJZk6SUtyznfo1ZB6
https://i.imgur.com/g7agrmg.png

bminer : https://zcash.flypool.org/miners/t1LLJPAoYajZjPQggPZcdDpwPont4AoGvfq
https://i.imgur.com/sjcIHk9.png

              Pool avg. hashrate          Payout
dstm               5.29kH               0.03619ZEC      
bminer            5.48kH               0.03847ZEC

If you are interested in seeing the full running logs, here it is: https://ufile.io/f2906

Note that my experiments should NOT be interpreted as a general experiment that can apply to all situations. The best way to find out which miners work best for you is to try it yourself.

To be honest, I see this as a healthy situation for all of us. As long as the difference between bminer and dstm is small, they will have to play fairly (for example, not raising devfees) and we get more choices.

If I have time, I may run a comparison again maybe on another pool. But I cannot promise because doing this takes a lot of energy.

That's very strange.
On my tests dstm constantly outperforms bminer on pool side.
It's even more strange since bminer reports localy a higher hash rate.

However my main concern is the private connection of this miner.
The dev can increase / decrease the fee anytime he want's.
Downgrading won't help us because of the private connection.
Actually he can do what ever he wants, that's why he put the private connection in, I'm pretty sure about this.
Supporting this kind of miners seems to be a very stupid thing for us to do - there is no other miner I'm aware of which requires a private connection - this miner requires a private connection to even start mining.

[cryptoyes]

Fully agreed on the private connection aspect. I said so myself, and specifically asked @realbminer about it. He didn't reply. He claims he cares about us though ...