Bitcoin Forum
September 22, 2018, 12:19:19 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
Author Topic: [ANN] Bminer: a fast Equihash/Ethash/Tensority miner for CUDA GPUs (10.3.0)  (Read 52714 times)
LoraineLY
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 06, 2018, 04:17:42 PM
 #721

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?
1537618759
Hero Member
*
Offline Offline

Posts: 1537618759

View Profile Personal Message (Offline)

Ignore
1537618759
Reply with quote  #2

1537618759
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
cryptoyes
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
February 06, 2018, 04:39:03 PM
 #722

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
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 06, 2018, 04:51:11 PM
 #723

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 Cheesy. 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
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
February 06, 2018, 05:04:35 PM
 #724

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 Cheesy (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
Full Member
***
Online Online

Activity: 294
Merit: 136



View Profile
February 06, 2018, 05:36:03 PM
 #725

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.

Quote
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 Smiley 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.  Tongue

DarkOsa
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
February 06, 2018, 05:54:27 PM
 #726

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.


What's the exact % of invalid shares, I wonder... I too thought that bminer has quite  high percentage of rejected shares until I switcher over from Nicehash to miningpoolhub and suprnova (haven't tested new release on flypool yet). Surprisingly, on NH I had 1.5-2.5% of rejected shares, but on MPH and suprnova I now have 0.4-0.3%, with the same setup and OC (that's 2-day statistics). So looks like rejected share rate varies from pool to pool.
LoraineLY
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 06, 2018, 06:00:59 PM
 #727

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 Cheesy (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
Full Member
***
Online Online

Activity: 294
Merit: 136



View Profile
February 06, 2018, 07:28:23 PM
 #728

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

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
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
February 06, 2018, 08:18:10 PM
 #729

@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 Sad. 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
Legendary
*
Offline Offline

Activity: 1148
Merit: 1020


Patience is the key..


View Profile WWW
February 06, 2018, 08:18:20 PM
 #730

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

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?

        ▄▄███████████▄▄
     ▄██▀▀           ▀▀██▄
   ▄█▀   ▄▄█████████▄▄   ▀█▄
  █▀  ▄███████▌ █▌ █████▄  ▀█
 █▀  ██  ██         ▀█████  ▀█
▐█  ██▀▀█████   ▄▄▄   █████  █▌
█▌ ▐██▄▄████▌  ████   █████▌ ▐█
█  ███  ████        ▄███████  █
█▌ ▐█▀▀████▌   ▄▄▄  ▀██████▌ ▐█
▐█  █▄▄████   ████   ▐█████  █▌
 █▄  ████           ▄█████  ▄█
  █▄  ▀████  ███  ██████▀  ▄█
   ▀█▄   ▀▀█████████▀▀   ▄█▀
     ▀██▄▄           ▄▄██▀
        ▀▀███████████▀▀
bitcore.
...The Future Is Now...
▄▄▄▄▄▄▄▄    ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄     ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

        ██
██████
        ██
        ██████
        ██
██████
        ██
        ██████
        ██
██████
                 ▄▄██
 ▄██████████████████████▄
█▀         ▄▄██▀▀   ██  ▀█
█▄     ▄▄██▀▀        ██  █
█▀█████████████████████████▄
█                          ▀█
█                           █
█              ▄████▄       █
█             ██▀  ▀██      █
█            ▐█▌    ▐████████
█             ██▄  ▄██      █
█              ▀████▀       █
█                           █
█▄                         ▄█
 ▀█████████████████████████▀
.
iOs
Android

        ██
        ██████
        ██
██████
        ██
        ██████
        ██
██████
        ██
        ██████


     ▄▄█████████▄▄
   ▄███▀▀     ▀▀███▄
  ███             ███
 ███               ███
▐██   ▐█▄   ▄███▄   ██▌
██▌    ███▄██████▀  ▐██
██▌    ▐████████    ▐██
▐██     ▐██████     ██▌
 ███   ▀█████▀     ███
  ███             ███
   ▀███▄▄     ▄▄███▀
     ▀▀█████████▀▀


     ▄▄█████████▄▄
   ▄███▀▀     ▀▀███▄
  ███             ███
 ███       ▄███    ███
▐██       █████     ██▌
██▌       ███       ▐██
██▌     ███████     ▐██
▐██       ███       ██▌
 ███      ███      ███
  ███             ███
   ▀███▄▄     ▄▄███▀
     ▀▀█████████▀▀


     ▄▄█████████▄▄
   ▄███▀▀     ▀▀███▄
  ███             ███
 ███         ▄▄█▌  ███
▐██      ▄▄█████    ██▌
██▌   ▄████████     ▐██
██▌  ▐████████      ▐██
▐██    ▀▀████       ██▌
 ███     ▀██       ███
  ███             ███
   ▀███▄▄     ▄▄███▀
     ▀▀█████████▀▀
Website
ANN
Block Explorer
MagicSmoker
Full Member
***
Online Online

Activity: 294
Merit: 136



View Profile
February 06, 2018, 09:17:14 PM
 #731

...
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
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 06, 2018, 10:44:03 PM
 #732

@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 Sad. 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
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
February 06, 2018, 11:00:20 PM
 #733

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
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 06, 2018, 11:08:55 PM
 #734

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
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
February 07, 2018, 12:06:35 AM
 #735

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
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
February 07, 2018, 12:31:31 AM
 #736

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
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 07, 2018, 12:56:02 AM
 #737

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
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
February 07, 2018, 12:58:54 AM
 #738

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
cryptoyes
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
February 07, 2018, 01:05:09 AM
 #739

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
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 07, 2018, 01:11:42 AM
 #740

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
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!