netboot: make the transfer round-trip efficient

Transfer now works on hardware -- the block counter climbs -- but slowly, with
some ACKs missing.  It is ROUND-TRIP bound, not bandwidth bound: stop-and-wait
means one block per round trip, so three things dominated and all three were
conservative bring-up choices rather than considered ones.

  - Block size 256 -> 1024.  A 298 KB image is 1166 blocks at 256 but only 292
    at 1024.  256 was chosen to stay near the only multi-page frame ever proven
    on hardware (a 342-byte DHCP broadcast); large frames are now safe because
    RBFI stops a full ring being overwritten and stop-and-wait keeps exactly
    one frame in flight, so five pages of a fourteen-page budget is never
    contended.  --block 256 remains as a fallback.

  - Host ACK timeout 0.5 s -> 0.1 s.  The round trip is a few milliseconds on
    a LAN, so half a second meant every lost ACK cost half a second.

  - The GC's TI poll slept 500 us up to 20 times, costing up to 10 ms per ACK
    even when the transmit succeeded immediately -- on every block.  It now
    polls without sleeping; a bba_r8 is itself tens of microseconds, so a bare
    loop samples often enough and returns as soon as TI sets.

Absence of TI is explicitly NOT fatal.  TI only means TXFrameDrain handed the
frame to the W5100, so the frame may well have gone out; and if it did not,
the host's retransmit covers it.  Blocking longer would slow the common case
to protect against the rare one.

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

gc_bba_test/README.md

@@ -149,6 +149,22 @@ ring ahead), resyncs and continues rather than parsing untrustworthy bytes, and
 reports the count on timeout — but detection is not prevention. A busy link
 will still cost retransmissions.
 
+### Throughput
+
+The transfer is **round-trip bound**, not bandwidth bound: stop-and-wait means
+one block per round trip, so block size sets the speed.
+
+- `--block` defaults to **1024** (292 blocks for a ~298 KB image). 256 was the
+  conservative bring-up value; drop back to it if large frames misbehave.
+- `--timeout` defaults to **0.1 s**. The round trip is a few ms on a LAN, so
+  the original 0.5 s made every lost ACK cost half a second.
+- The GC polls for TI without sleeping. A `usleep(500) × 20` loop cost up to
+  10 ms per ACK even when the transmit succeeded immediately — on every block.
+
+A missing ACK is not fatal: the host retransmits, and the GC re-ACKs a
+duplicate block rather than ignoring it, so a lost ACK recovers in one
+timeout. `txto=N` in the status line counts ACKs where TI never set.
+
 ### Stop-and-wait is load-bearing
 
 The gateware does not consume RRP, so `RXFrameAssembler` can overwrite ring

gc_bba_test/source/netboot.c

@@ -172,14 +172,20 @@ static int send_ack(u16 seq)
 	if (bba_tx_bytes(f, sizeof(f)) < 0) return -1;
 	bba_w8(REG_NCRA, NCRA_SR | NCRA_ST0);
 
-	/* Wait briefly for TI.  Not proof it reached the wire, but its absence
-	 * is a clear failure, and blocking here is fine: stop-and-wait means the
-	 * host is idle until this ACK lands anyway. */
-	for (i = 0; i < 20; i++) {
+	/* Poll for TI WITHOUT sleeping.  usleep(500) x 20 meant every ACK cost
+	 * up to 10 ms even when the transmit succeeded immediately, and the
+	 * transfer is round-trip bound -- that is 10 ms on every one of ~292
+	 * blocks.  A bba_r8 is itself tens of microseconds, so a bare loop polls
+	 * often enough and finishes as soon as TI sets.
+	 *
+	 * Absence of TI is NOT treated as fatal: the frame may still have gone
+	 * out (TI only means TXFrameDrain handed it to the W5100), and if it did
+	 * not, the host's retransmit covers it.  Blocking longer here would only
+	 * slow the common case to protect against the rare one. */
+	for (i = 0; i < 200; i++) {
 		ir = bba_r8(REG_IR);
 		if (ir >= 0 && (ir & IR_TI))
 			return 0;
-		usleep(500);
 	}
 	s_tx_timeouts++;
 	return -1;