https://gitlab.synchro.net/main/sbbs/-/commit/8beefc9c2679374e69975f23
Modified Files:
src/bench/zmodem/README.md fixC-buffered-producer.patch
Log Message:
bench/zmodem: window-full flush helps but does not fix windowed sends

Adds the zmodem.c half of the buffered-producer fix to the parked patch
and records why the pair still does not ship.

zmodem.c's window-full path logs, sets backchannel_wait and continues
straight back to the back-channel wait without a zmodem_flush(). A
per-byte producer never noticed, because everything it produced was
already in the ring; a buffered producer is left holding the ZCRCW that
was supposed to elicit the ACK. Adding the flush there is correct on its
own terms -- the sender is about to block for a reply -- and it helps:
-w32768 goes from a roughly one-second stall per window to completing at
1.36 MB/s, with no cost to streaming, which still measures 115.80 MB/s.

It is not enough. The shipped sender does -w32768 at 4.74 MB/s, so 1.36
is still a 3.5x regression, and the obvious next move makes it worse
rather than better: raising OutbufSize to 64 K so the SO_SNDBUF bound
exceeds the 32 K window times out entirely. So "bound at least the
window size" is not the missing rule, and windowed mode needs its own
diagnosis rather than another guess.

One thing that looked like a regression is not: -w8192 fails on the
shipped sender too, rc=-8 with nothing transferred, so that is
pre-existing and unrelated.

Both files are therefore back to HEAD and the combined change is saved as fixC-buffered-producer.patch with the measurements in the README. Also
note for whoever picks this up: 71 MB/s appeared once in a streaming measurement and was load noise from another build on the box -- re-run
before believing a throughput drop. Refs #1195.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net