Now, the somewhat interesting thing is, LP does not actually control when getworks happen. 100 mhash/sec causes nonce saturation in 45 seconds on a single getwork, and you have 2 getworks per GPU worked in parallel.
LP locking up due to network/pool stupidity only causes higher actual stale rates because LP isn't triggering getworks early. Any shares created until post-new block getwork are stale. It stops generating stales when the new getwork triggers.
I'm not sure I'm understanding this correctly - does this mean you don't use the LP response to update the current work? As I understood it, the LP response is the same thing as a normal getwork response and should be used as the current work, not trigger a new getwork request.LP locking up due to network/pool stupidity only causes higher actual stale rates because LP isn't triggering getworks early. Any shares created until post-new block getwork are stale. It stops generating stales when the new getwork triggers.
Anyway, not all the shares found after LP failure are rejected, only about 2/3 (which is annoyingly high, and probably caused both by my dodgy network connection and the low hashing speed). So normal getwork still works, that isn't a problem.
You're partly understanding it correctly. Look at the math I printed, a getwork lasts 45 seconds at 100 mhash/sec. There are 2 used per GPU. On my 5850@918, that is a getwork every 12 seconds on average (they come in groups of 2 every 24 seconds). An LP only causes a getwork up to 24 seconds early.
LP returns a getwork, it is reused, but that doesn't help the other threads. Thus, LP causes a getwork flush. Also, for my 5850, this also means I can only produce stales for up to 24 seconds. A terminally stuck LP thread will just cause spans of 24 seconds to be stale-happy. A block happens roughly every 8 minutes (although the network targets 10).
.
. Well some changes seem like we've got similar ideas or he already took a look ^^.