Host polling depth over T512-N4
Batching multiple launches before result copy/synchronization improves end-to-end throughput by amortizing host overhead.
Diagnostic work, exact algebra and local capabilities are not treated as end-to-end mining advantage.
What was tested?
Batching multiple launches before result copy/synchronization improves end-to-end throughput by amortizing host overhead.
Why the test is meaningful
Polling depth changes orchestration rather than SHA arithmetic; gains must be weighed against detection latency.
depth P∈{1,2,4,8}Rwall(P)=throughput(P)/throughput(P1)latency≈P·single-launch durationHow it was tested
Keep TPB512/NPT4 fixed, process 96 equal batches per run and test four unseen headers across 32 measurements.
What happened
P2, P4 and P8 ratios were 1.001861, 1.002225 and 1.002705. P8 was positive on 4/4 headers and its 95% interval 1.001201–1.004211 stayed above one, but it exceeded the gate on only 3/4 headers.
Exactness and statistical controls
Compiled depth, exact B32 results, spills and registers were audited. P8 remains a candidate pending independent replication.
What the result means
Host synchronization amortization is a plausible small local mechanism with an explicit latency tradeoff.
Limitations
- Discovery campaign only.
- Deeper polling delays work cancellation.
- Energy was not measured.
Evidence trail
Freeze P1/P8 binaries before new headers and replicate wall throughput plus polling interval.
Canonical variants
CANONICAL-EXP-149PREREGISTERED-CAMPAIGNSEALED-AUDITSource: internally audited canonical reports. Local filesystem structure, private headers and operational identifiers are excluded from publication.