One thing to consider is the overhead for queuing work and checking results: assume the serial communication goes over 115.2kbps 8N1, sending a job request takes around 4ms, if you added starting nonce and length about 5ms. Checking for results adds another ms.
At 800 MH/s the BitForce needs 5secs for the whole nonce range. Splitting up the work into e.g. 64 chunks to get latency down to 80ms will cost you about 350ms for communication. Thats 7% of total idle time for your BFL... Might still be worth considering as a mean to prevent chips from running hot
Unless the input/output is buffered before sent to the sha256 engine.
In that case it doesn't matter how often you send new work.
As folks said above: we need our BitForces to turn this speculation into a solid discussion. If BFL assumed that issuing a new work request while the engine is still busy invalidates current work, they might stop it as soon as they receive the 'ZDX' job request command.
Or they already knew about P2Pool and check for results supports incremental reporting and everything is fine. We'll see soon
Seems the answer is most likely: avoid p2pool for now until the next firmware version.
Assuming I understood the very short discussion I had with someone ...
1) The abort does not reply with anything already found
(my guess at understanding this is coz the abort is simply "start new work")
2) The results are returned at the end of processing the full nonce range.
So ... assuming a 820MH/s figure: nonce range takes: 5.24 seconds
So with an average 10 second LP without paid stales, that looks to me like you're gonna be throwing out a lot of work on p2pool.
