docs: record netboot throughput at 6.4 s and what txto=0 does and does not say

300908 bytes in 6.4 s (0.38 Mbit/s) with txto=0, down from 40.1 s and 16.9 s.
The whole cost was round-trip, not bandwidth: stop-and-wait is one block per
round trip.

The counter-intuitive result is recorded deliberately: raising the host timeout
0.1 -> 0.3 barely changed the retry count (110 -> 95) but tripled the cost of
each, making the transfer 2.4x SLOWER.  Short is correct here because the GC
re-ACKs a duplicate immediately, so a premature retry costs one timeout and
nothing else.  Anyone tuning this later will reach for a longer timeout first;
the note says not to.

Also corrects my own earlier claim.  I concluded from the 0.3 s result that the
misses were LOST ACKs rather than late ones.  txto=0 shows every ACK reached
the W5100 with TI set, so the drain and EXI side are clean -- but TI is not
proof of transmission, and a 6.4 s total is hard to reconcile with ~95 genuine
losses.  The honest state is that it is not established either way, and the
retry COUNT at 0.05 s is the measurement that would settle it.  Recorded as
open rather than fixed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -237,6 +237,31 @@ directly, so a broken test build costs nothing. Proven end to end on console:
 300076 bytes in 294 blocks, verify OK, Swiss boots, and new builds are now
 delivered this way instead of by SD card.
 
+**Measured 2026-10-09: 300908 bytes in 6.4 s (0.38 Mbit/s), `txto=0`.**
+
+Getting there was all round-trip cost, not bandwidth — stop-and-wait means one
+block per round trip. Three things mattered, in order of effect:
+
+| change | result |
+|---|---|
+| host `--timeout` 0.3 → **0.05 s** | 40.1 s → 6.4 s |
+| `send_ack` TI poll 200 → **8** | 200 EXI transactions ≈ 12 ms, spent only when TI was slow — i.e. exactly when the host was closest to timing out |
+| block 256 → **1024** | 1166 blocks → 294 |
+
+⚠️ **The timeout result is counter-intuitive and worth remembering:** raising it
+0.1 → 0.3 barely changed the retry count (110 → 95) but tripled the cost of
+each, so it made the transfer 2.4× SLOWER. Short is right here, because the GC
+re-ACKs a duplicate block immediately — a premature retry costs one timeout
+and nothing else.
+
+⚠️ `txto=0` means every ACK was handed to the W5100 with TI set, so the drain
+and the EXI side are clean. **TI is not proof of transmission**, so a residual
+retry rate points past the hand-off (the chip, or the wire). Whether the
+remaining misses are lost or merely late is NOT established — the retry count
+is roughly timeout-independent, which suggests loss, but the 6.4 s result is
+hard to reconcile with ~95 genuine losses. Get the retry count alongside
+`txto` before theorising.
+
 Details and the recovery ladder are in `gc_bba_test/README.md`. Key points:
 - **Raw ethertype `0x88B5`, not IP** — no ARP, no IP stack, no libogc network
   driver competing for the EXI channel. It reuses only `bba_tx_bytes()` and the