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

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

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.

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.

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!

@MagicSmoker ... whatever you say.

@realbminer: I found a quirk.


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" ?

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.

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.

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