Roflin
ada9378628
TIMING MEASUREMENT, which is the useful part. Raising the host timeout
0.1 -> 0.3 barely moved the retry count (110 -> 95) but tripled the cost of
each one: 16.9 s -> 40.1 s. If those were LATE ACKs, three times the deadline
would have all but eliminated them. They are LOST ACKs, so a SHORT timeout is
correct, not a long one -- the GC re-ACKs a duplicate block, so retrying early
costs nothing. Host default is now 0.05.
REGRESSION, mine, from 92f7d71. Inserting the RBFI handler split the TX-done
block, leaving these two lines attached to rx_overflow -- an RX event:
m.d.sync += r_ncra[1:3].eq(0) # clear ST bits
m.d.sync += tx_queued.eq(0) # ready for the next frame
So after the first transmit tx_queued stayed set forever. The NCRA ST
fallback trigger is guarded on ~tx_queued, so software driving TX via ST
rather than TWD would transmit exactly ONCE and then silently stop, and the ST
bits were left asserted in NCRA. Our own path arms via TWD, which is why it
kept working and why this was not noticed.
T9 covers it and is mutation-tested: with the clears misplaced, NCRA reads
0x0A with ST stuck set.
This does NOT explain the 1/3 ACK loss -- the TWD path was unaffected -- so
that remains open. txto from the next run is the discriminator: near zero
means the frames reach the W5100 and are lost after that, which points at the
chip's TX handling rather than the EXI side.
--seeds 8: clk 27.5-29.4 MHz, EXI 54.7-62.3 MHz, 8/8 PASS. Best seed 5
(clk 29.41, EXI 60.22), flashed. The .dol is unchanged; only send-dol.py's
default timeout moved, and that is read from the repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>