P16 per-kernel epoch cancellation
Checking a VRAM epoch once per P16 kernel can reduce polling overhead while keeping cancellation within 15 milliseconds.
Diagnostic work, exact algebra and local capabilities are not treated as end-to-end mining advantage.
What was tested?
Checking a VRAM epoch once per P16 kernel can reduce polling overhead while keeping cancellation within 15 milliseconds.
Why the test is meaningful
Coarsening checks amortizes control traffic; the response bound then depends on kernel duration and scheduling jitter rather than per-nonce polling.
work=67,108,864 hashes per launchretention=throughput(P16-epoch)/throughput(P16)pass iff 4/4 responses≤15 ms and retention≥0.9995How it was tested
Read the device epoch once per kernel, send updates on a prioritized stream, and execute 24 paired benchmarks plus four cancellations under exact B32 coverage.
What happened
Responses were 4.23, 5.84, 16.17 and 18.61 ms, so only 2/4 met the 15 ms gate. Retention was 0.999334 with CI95 0.998722–0.999947 and 0/4 favorable headers.
Exactness and statistical controls
Exact SHA-256d and B32 passed; compilation reported 44 registers and zero spills. The latency and retention failures were retained without reselection.
What the result means
P16 makes cancellation nearly practical but does not meet the all-trials latency or 0.9995 retention requirements.
Limitations
- Four cancellation trials give limited tail information.
- Kernel duration depends on device and clock state.
- The experiment does not support pool deployment.
Evidence trail
Freeze the P16 control and epoch binaries, preserve 2^32 audit coverage, and apply both gates without dropping slow trials.
Canonical variants
CANONICAL-EXP-164PREREGISTERED-CAMPAIGNSEALED-AUDITSource: internally audited canonical reports. Local filesystem structure, private headers and operational identifiers are excluded from publication.