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

[MagicSmoker]

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.

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.

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.

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.

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

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

[1715019009]

1715019009

[1715019009]

1715019009

[MagicSmoker]

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

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.

[cryptoyes]

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

Why mine a coin I don't think is the best in its class

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

[LoraineLY]

Right. Point of procedure for anyone who has some more potent hashrate, i.e. 5 kH/s and up.

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.

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

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?

[cryptoyes]

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

[LoraineLY]

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 .... setting dif=20000 and i get a share every 4.5 seconds, 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).

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.

[cryptoyes]

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.

Code:

hping3 -S -p 3333 cn1-zcash.flypool.org

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.

[MagicSmoker]

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

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.

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.

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

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

Yeah, totally spaced on that one. Mea culpa.

Why mine a coin I don't think is the best in its class

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.

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. 

[LoraineLY]

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.

Code:

hping3 -S -p 3333 cn1-zcash.flypool.org

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.

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.

[MagicSmoker]

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.

[cryptoyes]

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

[crairezx20]

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.

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?

[MagicSmoker]

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

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?

[LoraineLY]

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

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.

[cryptoyes]

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?

[LoraineLY]

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:16000@cn1-zcash.flypool.org:3333/ -api 127.0.0.1:1880 > bminerr1.log 2>&1

Code:

./bminer -uri stratum://t1LLJPAoYajZjPQggPZcdDpwPont4AoGvfq.bminerr2:16000@cn1-zcash.flypool.org: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

[cryptoyes]

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

[NinjaPickle]

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!

[LoraineLY]

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.

[Ventero]

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