Re: [ANN] Bminer: a fast Equihash miner for CUDA GPUs (5.3.0)
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.
...
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 
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.
