1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/bench/zmodem/README.md

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Jul 23 23:03:46 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/1c8c59b14b74fa47a4e82be9
    Modified Files:
    src/bench/zmodem/README.md
    Log Message:
    bench/zmodem: record the confirmed bottleneck and the batching dead-ends

    Update the README with the results of the throughput-redesign attempt:

    - Confirmed the send bottleneck is the producer's per-byte RingBufWrite
    (~11 MB/s vs ~85 for ztx_buf doing the same escape/CRC without the ring);
    consumer-side coalescing of the output thread was tried and did nothing.
    - Three distinct producer-batching prototypes (Fix A, Fix B, and a third
    that flushes on a threshold inside send_byte with error propagation) each
    reached ~66-88 MB/s and each FAILED the 3x error-recovery gate that the
    per-byte sender passes 3/3.
    - Root cause: batching decouples what zmodem believes it has sent from what
    is actually on the wire; ZMODEM error recovery (ZRPOS -> seek -> resend)
    assumes those track, and the buffered-but-unsent bytes are not reconciled
    on a reposition. A correct fix needs an abort/reposition-aware transport
    (a zmodem.c hook to purge the pending output buffer on ZRPOS/abort), which
    is a coordinated zmodem.c + sexyz.c/term.c change, not a transport tweak.

    No source change ships; the robust per-byte sender is retained. GitLab #1195.

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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Jul 23 23:03:46 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/904ab5e13a1f307d6f517d9a
    Modified Files:
    src/bench/zmodem/README.md
    Log Message:
    bench/zmodem: record the abort-aware-purge attempt and the recommended path

    The abort-aware transport fix was implemented and tested: a purge_output callback in zmodem.c (called from zmodem_handle_zrpos) that clears txbuf, re-inits the ring, and drops the output thread's linear buffer on every reposition, plus a bounded (2 KB) output-thread read. It fires correctly
    and gets the transfer noticeably further under errors, but STILL fails the multi-run error gate: under heavy corruption the block size collapses, retransmit storms fill the ring, the receiver gives up and the sender
    stalls. That is now five distinct batched-transport variants failing while
    the per-byte sender passes 3/3.

    Record the recommended path: re-architect the sexyz *sender* as a single-threaded, protocol-integrated buffered send (as lrzsz does) instead
    of the two-thread ring + output_thread, so the output buffer is owned by
    the protocol thread and flushed/repositioned synchronously with protocol
    state. That is a rewrite, not a patch. No source change ships; the robust per-byte sender is retained. GitLab #1195.

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

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