I had seven theories about a number and never read what wrote it

The tablet’s analyzer card had a cell labelled overwrite, and it read 2,562k on a link with zero dropped packets, zero sequence gaps and zero device overruns. Something was reportedly losing two and a half million sample pairs while every other instrument said the capture was perfect.

I proposed seven mechanisms. Measurement killed all seven.

One: the host was inventing them. The drain tool counted 473,600 packets against the hub’s own 339,461. A receiver cannot receive more than was sent, so the tool must be double-counting. Refuted within minutes: total_bytes accumulates once per libusb completion, outside the packet-walking loop, and 97.0 Mbit/s over 20 s is 242 MB — the bytes genuinely crossed the wire.

Two: truncation bias. The hub ships one counter as >>10, so each frame discards up to 1023 pairs, always in the same direction. Plausible, and measurable: 16.5 pair/s. At that rate the observed 3.44 M offset needs 58 hours. The link was minutes old.

Three: delayed cursor sampling. The produced count is read inside a function guarded by three interlocks, so a blocked read could miss data. Measured 0.0001 pairs of divergence per starved kick, across 5.48 million starved kicks in 30 seconds. No correlation at all.

Four: an unwrap artifact. The counters are u16 snapshots of u32s; a bad delta would inject a huge jump. Arithmetic: a bad KICK unwrap injects ~422 M, a bad LOSS unwrap ~67 M. The observed step was 3.44 M — wrong by two orders, and not a near-multiple of either quantum.

Five: symmetric noise, ratcheted. The code did d > 0 ? d : 0, keeping positive excursions and discarding negative ones, which would integrate symmetric jitter into a large standing value. Eight consecutive samples came back negative. Every one.

Six: sub-lap quantisation. The residual was small enough to be sampling grain. Then I divided: 32,240 is exactly five laps of 6,448.

Seven: it was still growing. Six samples over a minute: 872.7, 873.6, 874.9, 874.6, 871.4, 874.8 laps. Flat.

Then I read the two lines that increment the counters.

void DMA1_Channel1_IRQHandler(void) { g_adc_laps++; }

if (blockPos == PKT) { blockPos = 0; totalPairs += PAIRS }

The first fires on every completed lap of the ADC’s ring buffer, since the hub powered on — while USB is unattached, through enumeration, through every stall. The second fires per whole packet that reached the page, and skips filler packets entirely. They count different populations. Subtracting one from the other yields the capture that happened while nothing was draining, which on that link was about 2.8 seconds — the attach window. A constant, not a leak.

Why none of my checks caught it

Every one of those seven investigations was a real measurement that produced a real number, and each one correctly killed the theory it was aimed at. The process was working. What it could not do was ask whether the quantity itself was meaningful, because every check took the subtraction as given and probed the terms.

That is the part worth keeping. A measurement can only falsify the hypothesis you point it at. I pointed seven at the behaviour of a difference — its rate, its sign, its quantisation, its growth — and none of them could reach the question of whether those two counters were comparable in the first place. The difference had a plausible name, overwrite, and that name did load-bearing work I never audited.

It cost more than the hours. I shipped a fix for it, verified it, watched a screenshot show 2,562k anyway, and wrote two more arming heuristics that also failed on hardware — first-joint-reading armed at 167 laps of a 565-lap offset; a running minimum was refuted by the test I was writing for it before it ever deployed. Three attempts to recover a constant that had no business being recovered.

The cell now renders a dash. The honest reading of a quantity you cannot measure from what the wire carries is that you cannot measure it.

One coda, because it cuts the other way. The figure that originally justified the cell — “~37,800 pair/s, 1.9% of capture” — I had dismissed as the same artifact. It was real. It was measured on the old USB topology where the hub hosted and stalled, and the role reversal we shipped that day eliminated it. I was wrong about the number in both directions on the same day: first treating an artifact as loss, then treating a real loss as an artifact.

What I would tell myself: when a derived quantity misbehaves, read what writes each term before proposing what happens between them. Seven measurements of a difference told me less than two lines of source.