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

They are started at the same time around 1:09am UTC+8 or something. I am pretty sure the launch time difference of four rigs is within few seconds. It seems to me that bminer gets a lucky start and mined 1-2 shares before 1:10am window closes in flypool, while dstm does not. This causes an annoying extra bar in the bminer graph.

I will take screenshot after 24h and post the logs of all rigs.

I already understood this to be a factor, I just /assumed/ it wouldn't amount to much as long as I ran the test for 24 hours, the average time to find each share was a minute or less and the pool was also finding blocks frequently so that payout would tightly track share count. I also was skeptical that the average hashrate reported by a pool could be trusted any more than the average hashrate reported by a miner (after all, they both have some motivation to lie). Your argument is basically that my assumptions about variation in time to find a share (and pool reported hashrate - at least for Flypool) are incorrect? I have no problem abandoning these assumptions in the face of greater experience, I just want to make sure these are the errors I made.

I can't believe it took this long to get here, but this is more or less what I have been asking over and over again - which of my premises (ie - assumptions) were incorrect and why?

Any proof that this miner could mine faster that dstm i 1 rig of 1080ti and my mining run stable with dmts and my hashrate is 730-750 sol/s i can increase this more but i stay use the lower from the highest because the temp increases.
Well i'll test this tonight if this is faster than dmts miner..
Also can you share what setting you use for 1080ti?

@LoraineLY, please take a screenshot after 24h of the entire webpage at Flypool for each miner. It doesn't have to be 24h sharp ... it doesn't matter how much you overrun, really. Flypool does a running 24h window. Also please post the logs on pastebin after you stop both. The most important (to me) is to compare the reported hashrate by the miner vs what the pool actually gets from the miner.

EDIT: I just noticed that the two miners did not start at the same time . The logs would be less useful (still please post them). Make sure you leave each running for at least 24h ... and that you don't report payouts but hashrate.

@DarkOsa: you're always going to get more invalid shares on NiceHash with any miner, because nicehash will switch your miner from coin to coin (on the same algo) and thus adding likelihood of you submitting a share for the old coin (it just switched). When mining a single coin then 0.5% is what I noticed with bminer, but with dstm I usually have close to 0%.

@MagicSmoker, no, payout difference in your test doesn't mean one miner was faster. Sorry. You insisted on reporting payout instead of hashrate after 24h, which is what you were after (difference between hashrate reported by the pool vs. by the miner).

You asked about variability of luck when fixing difficulty of shares. One has nothing to do with the other. You can still find some shares in 0.1 seconds and others in 100 seconds even if average share time is 5 seconds. They are all paid the same though and there sometimes are periods of prolongued bad luck ... So you and your very slow rig for only 24h are bound to get variability in payouts that are at least as large as the difference in speed between bminer and dstm. Do it for 2 weeks and then I might take payout difference in account for that small hashrate.

You say you understand and don't want to be stubborn. I didn't see the hsminer thread you speak of, and while I did have quite a bit of patience (re-)explaining the reasons to you, I might understand the feelings involved in the other thread.

I shut down both miners at 2:02 - just a couple minutes late because I was out running errands - but that means I missed the first bar on the shares accepted/rejected graph. Not that it matters since my testing methodology was only destined to give inaccurate results... 

And though it will drive @cryptoyes crazy, the final balance for each miner was 0.00682 ZEC for dstm and 0.00698 ZEC for bminer, so bminer came in 2.3% faster.

Maybe when/if I get more 1080's I'll revisit this, but for now I'll hand off the torch to @LoraineLY.

I got my small experiments running. I have no confidence that my connection can stay beyond 24 hours uninterrupted, so in the end, I had to put 2 rigs for each miner.

bminer 5.3: https://zcash.flypool.org/miners/t1LLJPAoYajZjPQggPZcdDpwPont4AoGvfq
dstm 0.5.8: https://zcash.flypool.org/miners/t1SstC4pJy3JtKdqSoFJZk6SUtyznfo1ZB6

A few things to note:

1. I put a different worker name for each rig. I also collected logs for each rig.

2. Each rig has 6 GPUs (1080Ti and 1070). As cryptoyes mentioned, I am doing this for my own testing. You may get different miner behaviors if your rigs have a different setup.

2. I tuned the OC settings of bminerr1 to match the performance of dstmr1. I did the same for bminerr2 and dstmr2.

3. The difficulty is set to 16000.

Right, I understand that, the question is - and I'm really not trying to be difficult here - how much can the numbers possibly be skewed by variations in share luck if the difficulty is fixed?

For example, if I get a share every minute on average then that is 1440 shares in 24 hours. Every 1 share mismatch due to varying luck would then result in a 0.07% difference in effective earnings. Viewed from this perspective - which I cheerfully admit may be skewed... ahem - it's hard to see why I would need to set difficulty so low I'd then get a share every 5-10 seconds, or why I can't use actual earnings to evaluate miner performance rather than tediously counting up good shares from each of those teeny, tiny bars? Again, this is assuming share difficulty is fixed.

That said, I should note that you are not the only one to argue that earnings are not a valid metric for evaluating a miner, but the other people (in the hsrminer thread) didn't bother to explain their reasoning and/or simply resorted to calling me stubborn and silly.


Yes, that has been a persistent "feature" of bminer for several releases now.


Yeah, totally spaced on that one. Mea culpa.


Okay, gotcha. I guess I am on a bit of a hair-trigger after the deluge of asshole comments in the hsrminer thread.

I don't have a problem with your methodology - I can't duplicate it for the reasons I've mentioned before (mainly, insufficient hashrate vs. a very high minimum difficulty on Flypool) - I just want to understand the reasoning behind it and, especially, why my approach is so much worse it shouldn't be used at all/is guaranteed to be misleading/etc.

As for ZEC, now that I'll have a whopping big 0.016 or so when this test is done I'll have to keep mining it to get to an even 0.1 at least, because OCD. 

Try first with a single rig. The goal is to get a 5-10 sec share time. You can get this with either (a) slow rig & low diff or (b) fast rig & high diff. Option (b) is better because you'd be less prone to pool and blockhain variability in share difficulty during 24h (it wouldn't matter if you could get averages for, say, 96h) but is also more difficult to keep stable.

With diff=16000 and a 5.5 kh/s rig I get T=2 seconds, so you should be getting T=4 seconds with a 2.5 kh/s rig. If your ping to the pool is <30ms then you can just keep that. if you have a higher ping, increase difficulty to, say 18000, and try again.

You can test ping time using hping3 as that gives you the tcp response time on the specified port (rather than icmp time), though they should be very close.


My bet is that bminer over reports (my less rigorous tests so far showed that it does - i have yet to run a proper test though). However, like I said previously, if you have 6-7 or more GPUs on a single motherboard then you probably still want to use bminer because dstm and ewbf drop the hasrate by 5-7% within 60 seconds or so (too much irq servicing or system calling - I don't have the code, but I see the cpu hogged with irq serving). bminer is lighter on the CPU -- don't listen to the idiots telling you that the CPU doesn't matter in mining.

1. There is no way for me to hit 5.5k with a single rig. I will have to use two rigs for each miner then. Let's say they are dstmr1, dstmr2, bminerr1, and bminerr2.

2. Excellent. So I will try to make dstmr1 to match bminerr1 and make dstmr2 to match bminerr2.

3. I am from China. So I am pretty sure it is because of ISP or even the government . Strangely Asia server of nanopool usually is more stable for me if I use my vpn.
The cn port from flypool (without vpn) sometimes has package drops. I will try cn port of flypool today. Hope the network will not interfere my experiment.

I looked at Flypool myself right now and I can't set a difficulty lower than 16000 on one of my 5.5 kh/s rigs .... However, with dif=20000 i get a share every T=4.5 seconds on averate, so it should be possible to get a share every 7 seconds or so with a 2.5 kh/s if you set dif=16000. Try it.

1. Two rigs would make it more difficult to compare miner reports to pool reports, but it would still work as a last resort. But try first to see if you get 5-10 seconds share submit rate with a single rig at the lowest difficulty on flypool (seems to be 16000).

2. I use Linux too. I know the pain. Yes, you don't need card-to-card match, but rig-hashrate match (essentially you care for the pool to see the same capability from both rigs).

3. Flypool and ethermine (same servers) have been by far the most stable pools I have used ... for a long time. I'm surprised you're getting disconnections. You sure it's not something on your or your ISP's side?

You could also try YIIMP-based pools, but only those that have specific ports for each coin (most of them like zpool.ca or zergpool.com are algo-mining pools, with a port per algo and they automatically switch to the most profitable coion at the moment). unimining.net has this, but doesn't have equihash ...

There ar also pools with multiple ports with assigned difficulty ... I hate those. Some work as intended, some do not. Luckpool for instance will cap the diff at the highest available per port if your rig is too powerful (e.g. port 3056 for zen if your rig is >5 kH/s), most others will do vardiff no matter what port you chose (they just start you off with a higher/lower diff).

Hi cryptoyes. I am following your guide to do the setup. I have a few specific questions.

1. To reach 5kH and up, I need 2 rigs for each miner. I am fine to invest 4 rigs for the testing, but is that ok?

2. I am trying to tune the OC, but all my rigs are in Linux. I have to use command line nvidia-settings to tune the OC. It is extremely painful to have a card to card match between rigs. It will take hours and it is error-prone. Can I just tune the settings so that the total hash rate of a rig matches the total hash rate of another rig for bminer/dstm?

3. I have infrequent package drops (like 1 in 30-50) when connecting to flypool, but all 4 rigs for testing are under the exact same network environment. I guess it is ok?

I posted a detailed methodology above.

Perfect vs good is not the issue here. The issue is that you may be reporting skewed numbers which people would believe and choose the wrong miner as a consequence (you may also be unfair to one of the miners).

Yes, you can assign subsets of GPUs to miners. See the p.s. in my post above.

Flypool displays the accepted shares under the hashrate graph (the bars). You can hover your mouse over each and you'd see the exact number. That's going to be misleading though as each share has different difficulty. It's bloody HASHRATE at the pool that i kept saying matters for this test (even though payout is what you care about). Well, effective hashrate, i.e. after discarding invalid/stale shares.

It seems bminer gives more invalid/stale shares than other miners. Counting the ones you got so far (orange bars in FLypool), i see 96 invalid shares (normalized) for bminer, and 16 for dstm.

You are looking at the wrong number in dstm ... dstm does a full average on the right hand side, which stabilizes over time (doesn't jump around).

That's precisely why I wrote point 6 ... but it wasn't addressed to you (you already proved that you cared about testing and already invested time in it). If that's the only bit in my methodology post that you had comments on, then it's probably far better written than I thought and it would be a shame if it was buried in a flurry of replies.

p.s. Incidentally, ZEC has been more profitable to mine than all other equihash coins lately (it's one of the very few coins that had an uptrend during the ongoing onslaught of cryptos, check it out).

Now that was uncalled for. I wasn't worried about losing profits from mining ZEC, rather, I think it is inferior to ZEN. Why mine a coin I don't think is the best in its class (equihash anonymous payments)?

Really, let's try to keep the snark out of the discussion.

It's not that I don't agree with you - you explained yourself very well - it's that I simply can't do anything about the low hashrate. Sorry, unless more 1080's magically appear at Newegg for longer than 10 seconds and don't cost 2x MSRP I'm not going to be getting any more any time soon. I do have a 6x GTX 1060 rig, but even if I could assign 3 cards to each miner (don't think bminer lets you do this) that would get to ~900 sols/s hashrate for each, so not even twice as much.

So I realize my test is not *perfect* but as the old saying goes, don't let perfect be the enemy of the good.

As for counting shares vs. payout, please tell me how to extract that data from Flypool as I am not familiar with it and so far it looks like I have to add up all of the bars on the graph. That's a bit of a pain, really.


Correct, average time per share is around 45 seconds. But just like I can't buy any more 1080s right now, Flypool really does seem to have 8000 as a lower limit on difficulty; I already tried setting it to 2000 and the share rate barely changed.


Bminer is consistently reporting 550 Sols/s while dstm is a little less consistently reporting 530 Sols/s (that is to say, dstm's hashrate bounces around a lot more than bminer's).

Right. Point of procedure for anyone who has some more potent hashrate.

1. 2 rigs. Have 2 identical rigs that can do 3-5 kH/s each or so ... the more the better, but too much would entail variability between cards and higher likelihood of crashes. I wouldn't use more than 10 kH/s on this. EDIT: it looks like a 3kh/s rig should be able to get a 5 second share submission time on Flypool (see below).

2. Throttling. make sure the rigs don't throttle. This is very important. Either increase fans speed, or make the room cooler, or decrease TDP. dstm and bminer may also stress the cards differently, though I doubt it (if yes, then sure, I'd prefer the miner that stresses the gpu less but gets me the same hashrate).

Watch the temperature and stay below 60C if you can. NVIDIA gpus start throttling when the temperature is greater than 60C (trust me). Decrease TDP if the reported temperature is >59C. This is only for testing (you can increase your TDP back up after you're done). Memory and GPU overclock do not affect temperatures almost at all. TDP is virtually the only factor.

2a. Stability and comparability. Decrease gpu and memory MHz overclocking, and also TDP to make sure the rigs are stable (this is only a test and you want it to be reliable) and adjust gpu/mem/tdp on each rig such that dstm reports the same hashrate on both. That is, launch dstm and let it run for 5 minutes. It should report the same average hashrate on both rigs. In dstm, it's the right hand value on the totals line (not the left hand value that jumps around all the time). You really must ensure this, otherwise any results would be skewed ...

3. Difficulty. Start with difficulty DIF=10000. Choose a pool that allows you to set the difficulty, like Flypool (Nanopool does not! They fix the difficulty and you can't set it). Choose the pool server closest to you. Flypool allows you to choose between 4 locations (eu1, us1, cn1, asia1) and is a very reliable pool.

3a. now take one of the rigs and connect to flypool using bminer (not dstm) using , where DIF is the difficulty you set. This sets a fixed difficulty of DIF. Let it run for 5 minutes. bminer will report the number of accepted shares and number of rejected shares. Add the two values to get a total "N". Then compute the total number of seconds "SEC" for the mining session by subtracting the first timestamp reported by bminer from the last timestamp reported by bminer. Compute T=SEC/N (average share submission rate).

The goal is to get a 5-10 second share rate, i.e. 1 share submitted every 5-10 seconds. Lower is better as it means the hashrate at the pool will be more stable, but you don't want it too low because then ping times and other factors begin to matter. I would aim for 5 seconds if you have a good ping (<50ms), and up to 10 seconds if you have a bad ping. You can adjust the share time via the difficulty. If you see bminer submitting shares visibly faster than once every 5 seconds, then you need to increase difficulty. Specifically:

3b. If after 5 minutes T < 5, increase difficulty to DIF=20000 and go to step 3a. If T is a lot smaller than 5, then increase difficulty by more than double.

3c. If after 5 minutes T > 10, decrease difficulty to DIF=5000 and go to step 3a.

3d. If after 5 minutes 5 < T < 10, then you're good to go and can start the 24h test.

4. 24h test I would create new zcash wallet addresses for the final test, rather than use the same. Then you can share them with us without us seeing your past income and transactions. Then fire up both rigs at the same time, one with dstm, one with bminer, like so:

5. Finish. After 24h, stop. Upload bminer.log and dstm.log separately on pastebin.com. I'd be interested to check them out.

6. If you're worried about losing profits because you don't want to mine Zec or because you decreased your overclock for 24h then you probably shouldn't run this test (you also maybe, just maybe,  shouldn't really be mining in the first place).

Have fun.

p.s. If you want to use only a subset of cards from each rig, e.g. only cards 0,1,2,3, then add "--dev 0 1 2 3" for dstm, and "-devices 0,1,2,3" for bminer.

I have eight rigs with a total of 48 GPUs. Could I do the test on nanopool? My connections to flypool really sucks with infrequent but annoying package drops.

At the end of the day, I do not care the hash rate reported by miners. I am not accusing bminer numbers being fraudulent, but there is simply no way for us to know how miners report hash rates. The developer of bminer confirmed that the hash rate of bminer contains everything the hardware computed (accepted, rejected, and devfee). Other miners may count hash rate differently.

For me bminer shows roughly 3.5%-4% higher than dstm on my 1070. But if I take out the 2% devfee + whatever rejected rate I get, the difference between two is very close. My hypothesis is that dstm only counts accepted shares?

I will do a larger scale experiment with my eight rigs in nanopool to see which one works better for me. Trying to figure out which one is faster is so hard, especially when the difference is probably within 1% or 2%.

I keep saying "stop looking at payouts" but nobody listens ... oh well. I also said that such a petty hashrate will probably never give you reliable results ... oh well.

The two miners show 504 H/s and 529 H/s respectively so far in favor of DSTM, and while 25 H/s represents 5% of 500 H/s, in absolute terms this is totally within margin of error due to pool variations, share luck, PPLNS, choice of seeds for nonces that each miner makes, etc.

Also, the high jumps in hashrate in the graphs on suggest you're using a difficulty that is a bit too high and that your share submit time is not 5-10 seconds on average (see my previous post where I described this). I don't think you adjusted difficulty so that share submit time is 5-10 seconds.

There was a reason why I said I'd like to finalize my proxy software and release it. This week I'm too busy though.

Out of curiosity, what does DSTM and bminer report as average rates? I bet bminer says about 5% higher, right?

EDIT: someone said they have larger rigs they would be willing to use to test this. Please see my previous post: https://bitcointalksearch.org/topic/m.29688244 where I describe a methodology. Use Flypool. Use "10000" as your password when connecting to Flypool, which is the fixed difficulty you want, then adjust it after 5 minutes (and repeat) so that you get 5-10 seconds share submit time. Once you get that, let it run for 24h and read off the average hashrate of each miner from Flypool. Make sure the rigs are indeed identical, i.e. bminer/dstm reports the same hashrate on tboth. See my post for details.

This may be due to variations in luck on per-share basis, as @cryptoyes has been harping on (and which I simply can't do anything about given my present circumstances).

But yes, the variation seems to be quite small at this point. Still about 5 hours to go, though.

Both cards are plain GTX 1080 (not Ti) that I tuned with MSI AB so that bminer has the same hashrate on either card (or, conversely, that dstm has the same hashrate on either card).

The part I really cannot understand is that why flypool shows better hashrate for dstm but less payout?

Anyway, it seems to me that the difference is really within the margin of error. So it does not matter which one we use then?