Hm. Is there a way to replace pending work without potentially producing a pipeline stall?
E.g. is a RESET of the pending work followed by new work guaranteed to either successfully replace the work, or provide the next work, without ever halting processing?
For longpolling for transaction updates (or for P2Pool sharechain motion) you want them to happen as fast as possible, but not at the expense of stalling the pipeline (because the work is still useful).
For longpolling for chain motion, you also want to switch as fast as possible, but a stall is irrelevant since the work is actually useful (and stalling can be beneficial if it saves power over just waiting for the stale work to finish).
E.g. is a RESET of the pending work followed by new work guaranteed to either successfully replace the work, or provide the next work, without ever halting processing?
For longpolling for transaction updates (or for P2Pool sharechain motion) you want them to happen as fast as possible, but not at the expense of stalling the pipeline (because the work is still useful).
For longpolling for chain motion, you also want to switch as fast as possible, but a stall is irrelevant since the work is actually useful (and stalling can be beneficial if it saves power over just waiting for the stale work to finish).
Relevant?
Quote
Finally, there is no motivation to shortening the nonce range in order to drop work time down
to fractions of a second, because HashFast products allow work to be aborted, and in
particular with the GWQ protocol, the OP_WORK_RESTART mechanism provides a built in
command to seamlessly abort all work in progress and replace it with new work based on a
new coin base, as often as required and with negligible hashing downtime
to fractions of a second, because HashFast products allow work to be aborted, and in
particular with the GWQ protocol, the OP_WORK_RESTART mechanism provides a built in
command to seamlessly abort all work in progress and replace it with new work based on a
new coin base, as often as required and with negligible hashing downtime
OP_WORK_RESTART = awesome. The problem with many ASICs and p2pool is that p2pool generates "new" work on a short interval (about 30 sec between reward chain blocks). Without a OP_WORK_RESTART or something similar an ASIC will continue using "stale" work for a significant fraction of a second (or even multiple seconds). On Bitcoin network (600 sec average time between blocks) losing say 0.6 seconds to "stale work" means 0.1% stale shares but on p2pool with 30s average it is more like 2% ouch. This is in addition to other forms of stale shares due to network latency.
The ability to abort all work rapidly to all cores and supply new work should result in GN doing good things on p2pool.
