Quote from: MagicSmoker on February 02, 2018, 11:23:02 PM

Just passed the halfway point in my concurrent comparison of bminer 5.3.0 vs. dstm 0.5.8 and to make extra sure things are as fair as possible I flipped miners and rigs - bminer was on Rig 1 mining to Address 1, now it is on Rig 2 but still mining to Address 1, and vice versa for dstm.

The tally so far at the midpoint is 0.0327 ZEN for bminer and 0.0333 ZEN for dstm; less than a 2% difference, but with the advantage going to dstm now.

Testing will end tomorrow at 6:00AM EST and I will let immature shares settle for at least 1 hour before reporting results; luckpool finds blocks very often and provides an accurate tally of what you will earn for your shares, it just takes a while to move them from the immature column to confirmed, same as any other pool.

UPDATE - I just checked on the rigs and both miners were reporting they were hashing away just fine but the pool said bminer was offline. After restarting bminer the pool shows it back online again but there is a steep dip and rebound in the hashrate graph; earnings were affected as well, with dstm now at 0.0374 ZEN and bminer 0.0356 ZEN, so this wasn't a pool issue. I can't think of a worse failure mode for a miner, really - it was still drawing a huge amount of power and appearing to work, but not actually doing anything useful.

Could you share the failure log of Bminer? I would love to take a look.

It seems like a network issue that takes longer than usual to reconnect. Bminer does not shutdown GPU during reconnection, because it takes too long to re-init GPUs via Nvidia driver.

In future releases, I plan to add failover server support. I will also find a way to put GPU at idle states that draw less power during reconnection.