As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain
I was wondering if something like this was the case. Looking at the log that seemed to me what was happening, but I was having difficulty translating what was going on... (for one, the specific pool/device the message is about is rarely referenced in the logs!).
If there's not much you can do, there's not much you can do! I'll just stick to fail-over then
I'd say taking the dip in hashrate would be better option though. I prefer not to start work than throw away work done...
1. You won't waste power calculated hashes you know will be stale.
2. You don't get stales appearing in the stats.
