Bitcoin Forum
June 25, 2018, 01:24:00 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   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 »
  Print  
Author Topic: [ANN] Bminer: a fast Equihash/Ethash/Tensority miner for CUDA GPUs (9.0.0)  (Read 43820 times)
cryptoyes
Member
**
Offline Offline

Activity: 171
Merit: 10


View Profile
February 07, 2018, 01:15:36 AM
 #741

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).
1529889840
Hero Member
*
Offline Offline

Posts: 1529889840

View Profile Personal Message (Offline)

Ignore
1529889840
Reply with quote  #2

1529889840
Report to moderator
1529889840
Hero Member
*
Offline Offline

Posts: 1529889840

View Profile Personal Message (Offline)

Ignore
1529889840
Reply with quote  #2

1529889840
Report to moderator
The World's Betting Exchange

Bet with play money. Win real Bitcoin. 5BTC Prize Fund for World Cup 2018.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
LoraineLY
Jr. Member
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 07, 2018, 01:19:43 AM
 #742

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

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

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

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

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

Activity: 171
Merit: 10


View Profile
February 07, 2018, 01:26:43 AM
 #743

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).
LoraineLY
Jr. Member
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 07, 2018, 01:42:38 AM
 #744

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

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

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


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

Activity: 171
Merit: 10


View Profile
February 07, 2018, 01:48:21 AM
 #745

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

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

Activity: 171
Merit: 10


View Profile
February 07, 2018, 02:01:45 AM
 #746

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

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

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

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

Activity: 43
Merit: 0


View Profile
February 07, 2018, 02:20:03 AM
 #747

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

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

Activity: 43
Merit: 0


View Profile
February 07, 2018, 02:30:26 AM
 #748

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

Activity: 171
Merit: 10


View Profile
February 07, 2018, 05:23:24 AM
 #749

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.

feces
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
February 07, 2018, 07:16:20 AM
 #750

this software personifies my username.  demonstrate caution with its use.
LoraineLY
Jr. Member
*
Offline Offline

Activity: 43
Merit: 0


View Profile
February 07, 2018, 10:56:01 AM
 #751

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


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


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

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

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

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

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

Activity: 210
Merit: 55


View Profile
February 07, 2018, 01:06:54 PM
 #752

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

Activity: 18
Merit: 0


View Profile
February 07, 2018, 01:25:55 PM
 #753

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

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

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

Activity: 171
Merit: 10


View Profile
February 07, 2018, 01:26:31 PM
 #754

@MagicSmoker ... whatever you say.

@realbminer: I found a quirk.

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

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

Activity: 210
Merit: 55


View Profile
February 07, 2018, 01:35:50 PM
 #755

@MagicSmoker ... whatever you say.

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

cryptoyes
Member
**
Offline Offline

Activity: 171
Merit: 10


View Profile
February 07, 2018, 01:41:03 PM
 #756

Lol, just like the assholes in the hsrminer thread that kept saying I was wrong to use payout but never once explained why.
[...]
square that circle, because you can't have both be true.
I have no obligation to do anything (more) for you. You should do some reading before expecting strangers to explain it all to you, but not before you learn some manners. Also consider the following proverb: if you meet an asshole in the morning, then you just met an asshole; if you meet assholes all day, you're the asshole. Take care, kid.
Scorpio777
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
February 07, 2018, 01:54:12 PM
 #757

@MagicSmoker ... whatever you say.

@realbminer: I found a quirk.

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

When using a single card with high enough difficulty it's possible that a share is not found in a long time. It seems this happens when the pool doesn't send a new share within 5 minutes, but that's not an error, the miner shouldn't disconnect. Could you add an option to tune this time window please?
I agree, it will be very useful. In coinotron pool the shares difficulty is too high and for now i need to add comand "-gpucheck 0" and the miner don't restart every 5min if there are no Accepted Shares for 5 minutes, but sometimes it is very useful to restart miner when there are no Accepted Shares for more than 60min (for example).
resiva
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
February 07, 2018, 05:39:24 PM
 #758

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

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

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

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

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

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

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

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

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

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

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


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

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

Activity: 171
Merit: 10


View Profile
February 07, 2018, 05:55:26 PM
 #759

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

Activity: 210
Merit: 55


View Profile
February 07, 2018, 07:19:00 PM
 #760

To all who've been following the last couple of pages as the discussion between me and @cryptoyes turned nasty, I apologize both to you and @cryptoyes. In what will no doubt come as no surprise to @cryptoyes it was I who was in error and I actually took the proverb - and advice given - to heart by going back through the thread to try to find what I missed.

Turns out, the crux of the argument for using average hashrate reported by the pool rather than payout or even share count is that the average hashrate may not be trustworthy on an absolute basis - ie, the pool could be under-reporting it to skim a little extra for itself - but it should be trustworthy on an absolute relative* basis; that is, any doctoring of this value can be expected to apply equally to any given miner at any given time.

One only needs to know the time frame for the averaging function - ie, 24 hours - and make sure the length of the test is equal to or greater than that time.

Payout is /not/ a good metric because it is the sum of all shares found and that number can vary depending on luck as well as hashrate (assuming a fixed share difficulty is used; with vardiff share count is totally useless).

So, again, my apologies for cluttering up the thread and potentially misleading anyone with my flawed testing scheme. If there is any value in my repeating the test with my lowly dual 1080's I will in a few days.

* - oops, a really bad mistake here; fixed.
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 »
  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!