Ah, ok, I see. So basically any nonce that it reports (every 5 seconds) are anything from 0 to 5 seconds old. Yeah that's sucky. Let's hope BFL implements are better protocol in their ASICs.
The protocol made perfect sense for the main chain (5s wait time on a 10m block is just fine) but it was expected that running through the entire chunk of work and returning one "best" nonce for the whole block would be more efficient, but the assumptions break a little bit for the really short timespan between blocks on the P2Pool chain.
That's one of the things we were talking about up higher, because even the jalapenos can finish a block relatively quickly the stale rate should be low even if it has the same behavior.
Theoretically, if the Bitforce Single's bitstream was changed it could report back sooner, and I think BFL was looking into that briefly, but focus has definitely been shifted off of the old singles by now anyway.
No it never made sense.
It is the only device with the problem.
Because it is silent for 5 seconds each time, it means that on average, every block it wastes 2.5 seconds of hashing time.
i.e. on average every 600 seconds it wastes 2.5 seconds i.e. 0.4%
... for no reason at all except the designers were bitcoin noobs who thought they knew better than those who told them otherwise.
... and to add insult to injury, the actual understanding of the problem is that when you abort work it doesn't tell you what it has done already - there is no way to ask it the current answers it has found.
You abort work by telling it to start new work and throw away any current results.
So these issues give you the two options as I have already discussed.
