Author

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

newbie
Activity: 23
Merit: 0
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?
full member
Activity: 420
Merit: 184
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 Grin.

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  Grin). 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!
newbie
Activity: 43
Merit: 0
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.
member
Activity: 297
Merit: 10
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.

newbie
Activity: 43
Merit: 0
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 Grin.

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  Grin). Anyway, bminer still gets a little bit more payout, but dstm is trying to catch up.
newbie
Activity: 43
Merit: 0
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.
member
Activity: 297
Merit: 10
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.
member
Activity: 297
Merit: 10
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).
newbie
Activity: 43
Merit: 0
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.
member
Activity: 297
Merit: 10
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 ... Cheesy. 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).
newbie
Activity: 43
Merit: 0
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
member
Activity: 297
Merit: 10
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).
newbie
Activity: 43
Merit: 0
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
member
Activity: 297
Merit: 10
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.
newbie
Activity: 15
Merit: 0
Hey guys,

I would rly like to use bminer Dashboard but I cant connect to http://127.0.0.1:1880

It tells me "This site can’t be reached. 127.0.0.1 refused to connect."

Im using HiveOS


thanks for help
newbie
Activity: 43
Merit: 0
Of course invalid/share shares matter! They decrease your pay by exactly that amount. They are shares that the miner spent time mining but either computed wrongly (e.g. too much overclock, noise in the power stage, etc) or submitted them after the pool issued a new job. You want 0 invalids. Right now I see bminer issued between 0.5% and 1% invalids (just looking at the Flypool bar graph). That's how much money you are throwing away. It's a lot (you give 2% + 1% already to the miner and pool).

Can you please upload the current log files on pastebin? The hashrate at Flypool is more stable, but I'd have expected it to be even more stable for that diff and hashrate level.

Also, can you please run "hping3 -c 30 -S -p 3333 cn1-zcash.flypool.org" and copy the output to another pastebin?

p.s. The fact that you're using 2 rigs under the same workername makes no difference to difficulty (each rig gets the same share difficulty, regardless how it's connected to the pool).

Bminer right now has 0.4%-0.5% reject rate. Sure I would love to get 0.5% more pay if possible, but I guess I have to wait for my ISP to improve network or the dev of bminer to improve his software.

On the other hand, I think the reject rate does not interfere our comparison of two miners, if we are looking at pool reported hash rate or payout (I know you advocate to only look at pool hash rate, but I will just report both). Both of these numbers ignore the rejected shares. Bminer now seems to have a small upper hand over dstm. We will see what happens next.

Below are my hping results. All four rigs are similar. Seems so far a good day for me on flypool.
Code:
HPING cn1-zcash.flypool.org (enp9s0 116.211.167.195): S set, 40 headers + 0 data bytes
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=0 win=29200 rtt=39.7 ms
len=46 ip=116.211.167.195 ttl=35 DF id=0 sport=3333 flags=SA seq=1 win=29200 rtt=39.7 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=2 win=29200 rtt=39.5 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=3 win=29200 rtt=39.4 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=4 win=29200 rtt=39.0 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=5 win=29200 rtt=38.8 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=6 win=29200 rtt=39.6 ms
len=46 ip=116.211.167.195 ttl=35 DF id=0 sport=3333 flags=SA seq=7 win=29200 rtt=39.6 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=8 win=29200 rtt=39.4 ms
len=46 ip=116.211.167.195 ttl=35 DF id=0 sport=3333 flags=SA seq=9 win=29200 rtt=39.3 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=10 win=29200 rtt=51.1 ms
len=46 ip=116.211.167.195 ttl=35 DF id=0 sport=3333 flags=SA seq=11 win=29200 rtt=51.0 ms
len=46 ip=116.211.167.195 ttl=35 DF id=0 sport=3333 flags=SA seq=12 win=29200 rtt=44.2 ms
len=46 ip=116.211.167.195 ttl=36 DF id=0 sport=3333 flags=SA seq=13 win=29200 rtt=46.8 ms

Unfortunately, the log now already exceeds 500KB the maximum pastebin free supports. I will try to figure out another way to upload logs.
newbie
Activity: 45
Merit: 0
I'm writing a little windows program with a GUI to help configure the settings and start the miner for the user.  However, I noticed when bminer starts, it immediately spawns a second process.  This is problematic because I only know the PID of the the first process, while the actual miner is running in the second process.

I can't shut down the actual miner by PID, and have to do it by process name.  Normally this would be OK, except where the user wanted to run multiple copies of bminer (one for cards 0, 1, 2 and a second copy for 3, 4, 5 for example).  I would end up shutting down both instances.

So my question is, why the double process?  Any suggestions on how I know which 2 processes go together?

Thanks!
member
Activity: 297
Merit: 10
Of course invalid/share shares matter! They decrease your pay by exactly that amount. They are shares that the miner spent time mining but either computed wrongly (e.g. too much overclock, noise in the power stage, etc) or submitted them after the pool issued a new job. You want 0 invalids. Right now I see bminer issued between 0.5% and 1% invalids (just looking at the Flypool bar graph). That's how much money you are throwing away. It's a lot (you give 2% + 1% already to the miner and pool).

Can you please upload the current log files on pastebin? The hashrate at Flypool is more stable, but I'd have expected it to be even more stable for that diff and hashrate level.

Also, can you please run "hping3 -c 30 -S -p 3333 cn1-zcash.flypool.org" and copy the output to another pastebin?

p.s. The fact that you're using 2 rigs under the same workername makes no difference to difficulty (each rig gets the same share difficulty, regardless how it's connected to the pool).
newbie
Activity: 43
Merit: 0
So far bminer has a lot more stale shares (click on "Valid normalized" to hide those, you will only see the orange ones).

Something is not right though. What is the exact command line you used for each of the miners?

As MagicSmoker mentioned, bminer has a "feature" which generates more rejected shares than dstm. I am not surprised to see slightly more invalid shares with bminer than dstm. I think invalid shares do not matter in mining. Only the amount of generated valid shares matters.

Here are the command lines I used to run each:

Code:
./bminer -uri stratum://t1LLJPAoYajZjPQggPZcdDpwPont4AoGvfq.bminerr1:[email protected]:3333/ -api 127.0.0.1:1880 > bminerr1.log 2>&1

Code:
./bminer -uri stratum://t1LLJPAoYajZjPQggPZcdDpwPont4AoGvfq.bminerr2:[email protected]:3333/ -api 127.0.0.1:1880 > bminerr2.log 2>&1

Code:
./zm --server cn1-zcash.flypool.org --port 3333 --user t1SstC4pJy3JtKdqSoFJZk6SUtyznfo1ZB6.dstmr1 --pass 16000 > dstm-r1.log

Code:
./zm --server cn1-zcash.flypool.org --port 3333 --user t1SstC4pJy3JtKdqSoFJZk6SUtyznfo1ZB6.dstmr2 --pass 16000 > dstm-r2.log
member
Activity: 297
Merit: 10
So far bminer has a lot more stale shares (click on "Valid normalized" to hide those, you will only see the orange ones).

Something is not right though. What is the exact command line you used for each of the miners?
Jump to: