backlog: file #320 — windows-2025 MLLP ingress is ~10x slower than a healthy runner

[wshallwshall]

Diagnosis only. One file, one new BACKLOG entry, no code change.

The CI symptom was already fixed in #115 (06fd327d) by widening the reconcile's stranding budget. That fix was correct — a saturated-but-lossless run is not a correctness failure — but it deliberately did not address why the runner saturates. This files that.

The finding

tests/test_load_runner.py offers 60 msg/s for 1.5s (90 messages, pool_size = 4) at a listener whose ingress is strictly serial per connection — mllp.py:1433 is read chunk → for each frame → await handler → next, and the handler is the durable commit the ACK depends on. Total ingress = pool_size ÷ per-message-commit-latency. On windows-2025 that product is under 60/s.

Reproduced by raising the rate alone

Same profile, same code, same run_load path, on a healthy developer box:

offered	sent	acked	stranded	engine_read
60/s	90	90	0 (0.0%)	90
300/s	450	450	0 (0.0%)	450
600/s	900	444	456 (50.7%)	452

windows-2025 at 60/s: 90 sent, 44 acked, 46 stranded (51.1%), read 52. That is the 600/s row at one tenth the offered rate.

windows-2025 hits at 60/s what a healthy box hits at 600/s.

Why file it when nothing was lost

The same counters recurred byte-identically on two different commits — 9b03057f and 56f7d240, both 90/44/46/52. That is deterministic queueing, not runner weather, so it will recur on any profile whose offered rate approaches that leg's service rate. And it is invisible to a correctness check, because delivery was complete every time: 104 written, 104 received, backlog drained in 4.7s of a 30s bound.

It also corrects the record

harness/load/report.py justified the old budget with "observed teardown stranding is ~16%, so half is ~3x the worst seen." Both halves are wrong: healthy stranding at this rate is 0% (the 16% was itself measured on a partially-saturated run), and "half" was ~1.0x the worst seen by the time it red main, not 3x.

Stated as unknown rather than guessed

Not determined: why that runner's per-message commit is ~10x slower. Disk/fsync on the hosted image, Defender scanning the temp SQLite DB, CPU contention — all plausible, none measured, and not measurable from outside the runner.

Adjacent, unverified: at saturation engine_read (452) cleared the unconditional anti-vacuity floor read >= sent // 2 (450) by two messages. A floor breach is a hard failure no budget widening can rescue. A 1200/s probe did not reproduce it, but that run is not comparable — its drain timed out (max_drain_seconds = -1.0) and it took the branch that skips the settle-poll. Recorded as untested, not disproven.

Ledger

Number allocated atomically via scripts/coord/alloc.ps1 (not hand-picked). ledger_check.py --ci exits 0. #107's #1000 floor is not yet on main, so #320 is below it and will be grandfathered once merged — same sequencing as #318/#319.