From 8691b096764fea0948f4df3d3edb5f8708c1cc03 Mon Sep 17 00:00:00 2001 From: Dennis Brentjes Date: Fri, 9 Oct 2026 19:56:13 +0200 Subject: [PATCH] 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 --- CLAUDE.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 22e19a3..0139dad 100644 --- a/CLAUDE.md +++ b/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