https://gitlab.synchro.net/main/sbbs/-/commit/142d6aa509d91e348bd28dd2
Modified Files:
docs/zmodem_comparison.md src/bench/zmodem/README.md
Log Message:
docs/zmodem, bench: correct SyncTERM/localhost/recall claims (per Deuce)

Deuce (SyncTERM's author) corrected three framings; retained with caveats:

- "SyncTERM ~85 MB/s (faithful ztx_buf model)" is wrong. ztx_buf models the
SHAPE of SyncTERM's send path but under-measures its throughput ~3x
(Python-relay harness + poll-per-subpacket). SyncTERM's speed is a
deliberate BDP / socket-buffer choice (~75% of a 1Gb LAN), not an emergent
send-path fact. Relabelled ztx_buf as a "buffered floor (harness)" and
flagged ~85 as a localhost floor, not SyncTERM, throughout.
- The "recall stale bytes / abort-aware purge on ZRPOS" root-cause framing
(bench README) was a wrong garden path: you can't recall bytes once they
hit the network buffers, and lrz doesn't either yet recovers. The batched-
sender failures were implementation bugs, not inherent to batching.
- These are localhost CPU microbenchmarks; below ~8ms RTT the socket buffer
dominates the send loop. Optimizing it for localhost is largely beside the
point; the send-loop rewrite pays off only on fast LANs.

Also fixed a stale "fixed" on the ring-per-byte row (the batching prototype
was reverted, not shipped).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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

https://gitlab.synchro.net/main/sbbs/-/commit/9627d6504cecd3c53ff66c47
Modified Files:
docs/zmodem_comparison.md src/bench/zmodem/README.md
Log Message:
docs/zmodem, bench: re-measure after Deuce's send-path work; root-cause sexyz

Every throughput figure is re-measured in one interleaved batch (256 MB,
three passes, spread under 2%) so the tables are internally consistent
instead of splicing runs from different days: lrzsz 203.9, zmodem.c
rev 2.3 buffered floor 115.8, sexyz receiving 113.3, Forsberg 96.9,
zmodem.c rev 2.2 buffered floor 91.9, sexyz sending 11.5 MB/s.

Deuce's 2026-07-24 work on the shared send path (class-table byte
classifier, slicing-by-4 CRC-32, hoisted escape mask with noinline cold
paths, buffered fcrc32) moved the buffered floor 91.9 -> 115.8, +26%,
which SyncTERM inherits. The doc's old "second, shared lever, pending"
framing is replaced with what actually shipped.

Root-cause the sexyz sender properly rather than asserting it.
send_byte() takes the ring mutex twice per byte while output_thread
hot-loops on the same mutex: 44 CPU-seconds per 256 MB against lsz's
0.95, 1,464,130 voluntary context switches against 1,402, one futex per
17 bytes with 37% contended, and ~94-byte socket writes. A full sweep
of OutbufSize, OutbufHighwaterMark and OutbufDrainTimeout is flat inside
noise, so this is not a tuning problem and should not be chased as one.

Record the prototype ladder and what each one proved. Buffering the
producer removes the entire sexyz-specific penalty -- 115.8 MB/s at 1.0 CPU-second, exactly the engine ceiling -- but six variants now fail the
3x error-injection gate that the shipped per-byte sender passes. Two
results are worth keeping: rate-capping the batched sender to the
shipped sender's own 11 MB/s still fails while the shipped sender passes
3/3, so it is not an artifact of the higher data rate; and going single-threaded with a buffered send_byte holds full speed, drops
context switches to lsz's level, and reaches 2/3, leaving blocking
sendbuf() as the one missing piece. The recommendation is now what lrz actually is: single-threaded, buffered, non-blocking output with select
on both directions.

Also note the failure modes that cost time to rediscover (a void flush
callback swallowing a failed write, a sticky error latch spinning on zmodem_send_raw ERROR, position accounting desync) and that a
single-stream localhost benchmark cannot see per-byte CPU wins above
~100 MB/s -- two of Deuce's optimizations measure zero here because his
six interleaved 1 GiB transfers are CPU-saturated and this is not.

No code changes: all prototypes were measured out-of-tree and discarded.
Refs #1195, #1196.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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

https://gitlab.synchro.net/main/sbbs/-/commit/3d5c82cfc2265f8f131969c1
Modified Files:
docs/zmodem_comparison.md src/bench/zmodem/README.md
Log Message:
docs/zmodem, bench: 115.8 MB/s is a harness stall, not an engine ceiling

The previous commit treated the 115.8 MB/s "buffered floor" as zmodem.c's
CPU limit and built three conclusions on it. Measuring what the senders actually consume shows that is wrong:

ztx_buf (rev 2.3 + buffered send) 115.8 MB/s 0.69 CPU-s 30% CPU
lsz 203.9 MB/s 0.98 CPU-s 77% CPU

The engine does the same 256 MB in 30% less CPU than lrzsz and sits idle
for 70% of the wall clock; extrapolated to their CPU limits it is roughly
371 MB/s against lrzsz's 261. The receiver is not the constraint either,
since the same lrz absorbs 203.9 from lsz. So after Deuce's 2026-07-24 send-path work the engine is cheaper per byte than lrzsz's inlined loop,
and 115.8 is where ztx_buf's own I/O pattern stalls -- a blocking write()
per zmodem_flush and a poll() per subpacket in data_waiting. Under
strace -w, 93% of its in-syscall wall time lands in those polls; the
exact stall mechanism is not isolated and the doc says so.

Three claims are retracted. The 115.8 figure is not an engine ceiling.
The residual gap to lrzsz is not an escape/CRC deficit, so handing
send_byte a span would shave CPU that is not being spent -- that
recommendation is downgraded from "the second lever" to "done, and no
longer the lever". And the sexyz prototypes were not pinned by the
engine: all of them ran at 30-36% CPU because they share the same blocking-flush-per-subpacket shape, so a genuinely non-blocking sender's ceiling is unmeasured and plausibly above lrzsz's 203.9. That makes the transport rewrite more attractive than the previous commit implied, and
makes the next useful measurement a non-blocking prototype rather than
more engine micro-optimization.

The bench README gains the lesson that caused this: always record CPU
alongside goodput. A goodput number with no CPU figure beside it cannot distinguish fast code from idle code, and ztx_buf needs its own I/O
pattern fixed before it can serve as a reference at all.

No code changes. Refs #1195.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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

https://gitlab.synchro.net/main/sbbs/-/commit/c55eef72078c25e2b7322309
Modified Files:
docs/zmodem_comparison.md src/bench/zmodem/README.md
Log Message:
docs/zmodem, bench: lrzsz uses blocking stdio; a real flush() is not the fix

Two revisions of these documents told the reader that lrzsz's sender uses non-blocking output with select() on both directions, and that supplying
sexyz with the same would close the error-recovery gap. Reading the
source shows the first claim is false, and building the thing shows the
second one does not follow.

What lsz actually does: output is putchar/fwrite into stdout
(zm.c:109-110), flushmo() is fflush(stdout) (zglobal.h:411), and there is
no O_NONBLOCK, fcntl or FIONBIO anywhere in lsz.c or zm.c. The only
select() in the sender (lsz.c:754) is the pre-handshake purge that drains
stale input before ZRQINIT, not part of the data path. Escaping is a
lookup table with fwrite() of unescaped runs (zm.c:285-320) -- both the class-table idea Deuce landed this week and the "hand send_byte a span"
idea, present since the 1990s. Its per-subpacket loop (lsz.c:2093-2120)
is ZSDATA, then fflush(stdout), then a while (rdchk(fd)) loop that drains
the back-channel to empty. The property is "everything is on the wire
before you look for a reply", with blocking I/O throughout.

That did suggest a real difference: sexyz's flush() callback is a no-op
on the socket path -- it only fflush(stdout)s, and only in stdio mode --
so zmodem_flush() returns with the bytes still sitting in the ring.
zmodem.c already has the matching drain loop and already calls
zmodem_flush() per subpacket, so sexyz was the only piece not holding up
its end. Prototype v8 supplies a flush() that waits for the ring to
drain: full speed at 115.8 MB/s, and the error gate still fails, 1/3.
Worth fixing on its own merits, but it is not the cause.

Eight prototypes in, the useful output is the exclusion list, now
recorded: it is not the data rate (rate-capped control), not the batch
size (64 B to 4 KB all fail), not dropped or latched errors, not
flush-to-wire ordering, and only partly the output thread (removing it
moves 0-1/3 to 2/3 without fixing it). The mechanism is unidentified,
and the recommendation changes accordingly -- the next step is to
instrument a failing run and find what the receiver sees after a ZRPOS
that it does not see with the per-byte sender, rather than build a ninth prototype.

No code changes. Refs #1195.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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

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.

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