https://gitlab.synchro.net/main/sbbs/-/commit/8d8af7d5d090c3077ef615d5
Modified Files:
docs/zmodem_comparison.md src/bench/zmodem/README.md
Log Message:
docs/zmodem: re-baseline the throughput tables on a receiver that can
keep up

Every sender figure this document ever published was measured against
`lrz`. Section 3.5 then measured `lrz` itself and found it receives 256
MB for 1.28 CPU-seconds, with receiver CPU equal to the wall clock --
more expensive than any sender it was scoring. So the sender table was reporting `lrz`'s ceiling four times over and reading it as a four-way
tie ("every sender built on zmodem.c now runs level with lrzsz").

Deuce spotted it from the outside: switch the baseline receiver, lrz
can't handle the load. He is right about the premise. `zmrx` is the
obvious replacement at 0.94 CPU-s, but as of zmodem.c 2.7 it is no
longer the cheapest receiver -- the span work put sexyz itself at
0.55 s. So the baseline receiver is now sexyz.

Re-measured (256 MB, five passes, interleaved, medians), the senders
spread over 1.74x where they had sat inside 1.6 %:

zmtx 487.2 MB/s 0.47 CPU-s
ztx_buf 385.4 0.70
sexyz 335.3 1.00
lsz 279.9 0.96

sexyz sends 20 % faster than lsz, which the old baseline could not show.
The document says plainly that this is concurrency rather than
efficiency -- sexyz spends more CPU than lsz and wins on wall clock with
two threads -- and that the engine's efficiency claim belongs to
ztx_buf, single-threaded and cheaper than lsz on both axes.

The receive table of 3.5 had the same defect in the other direction: its
fixed `lsz` sender costs 0.96 CPU-s, so after the span fix the three
fastest receivers all read ~280 MB/s and the fix looked like it had
merely drawn level with `zmrx`. Driven by `zmtx` (0.47 s) instead, sexyz receives at 486.5 MB/s for 0.55 s -- 1.70x `zmrx`, the fastest receiver measured, and 4.2x its own pre-fix 117.2 at 24 % of the CPU. The
pre-fix rows were never affected, being the slow end either way, so the
deficit that section diagnoses stands as measured.

New section 3.0.2 states the rule both halves of this document have now
broken: the fixed end of a comparison must be cheaper in CPU than
everything at the varied end, and that must be shown rather than
assumed. The per-endpoint `wait4` CPU columns added on 2026-08-24 make
it checkable -- if the fixed end's CPU equals the wall clock, the run
measured the fixed end. The bench README carries the same lesson, and
its recipes no longer default to `lrz`.

Also recorded: the span receiver's cost depends on the sender's write granularity. Behind zmtx's 8 KB subpackets it receives for 0.55 CPU-s;
behind Forsberg's 1 KB blocks the same receiver spends 1.34 s and 256 k
context switches for the same bytes.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)