https://gitlab.synchro.net/main/sbbs/-/commit/7471d1b776cb2d7ea274a41e
Added Files:
docs/zmodem_comparison.md
Log Message:
docs: add ZMODEM implementation comparison (sexyz vs lrzsz vs rzsz)

A performance, scalability, and robustness analysis of Synchronet's ZMODEM (sexyz + the shared zmodem.c, which SyncTERM also uses) benchmarked against lrzsz 0.12.21rc and Chuck Forsberg's final rzsz 3.73 (modern branch).

Headline findings, all empirically measured:

- sexyz's sender is ~25x slower than lrzsz's lsz on a fast link (~8 vs
~204 MB/s), from two stacked overheads isolated by linking the real
zmodem.o behind two send paths: zmodem.c's per-byte callback + escape +
CRC design caps any sender at ~26 MB/s (shared, so SyncTERM inherits it),
and sexyz.c's ring-buffer + output-thread drops that a further ~3x to
~8 MB/s (sexyz-only; a futex storm + ~84-byte writes). SyncTERM avoids
the second layer, so its upload runs ~26 MB/s.
- A windowed (-w) send hangs the instant the file offset crosses 2 GiB:
zmodem.c narrows transmit-window/ACK positions to signed int32_t. Shared
with SyncTERM. The data path (fseeko/int64) is otherwise 64-bit clean;
4 GiB is a hard protocol ceiling (32-bit wire position field).
- sexyz's receiver is fine past 2 GB; Forsberg's sender runs ~92 MB/s but
its receiver won't complete headlessly (serial-tty assumptions).

Includes a conditions matrix (block size, CRC, latency, bandwidth
asymmetry, injected errors) and per-finding attribution to sexyz.c vs the shared zmodem.c vs SyncTERM's term.c. Relates to the sexyz-throughput and 2-GiB-window GitLab issues.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)