From 2ef0c215ea4af421a4b22ab543a5999320998f68 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sun, 11 Oct 2026 20:47:42 +0200 Subject: fix(node): a receive buffer that holds an upload's window Uploads ran at 6.5 MB/s because the kernel dropped datagrams at the node's 256 KB socket. Asking for 4 MB gave 19.5 MB/s, no drop. Co-Authored-By: Claude Opus 5.5 --- CLAUDE.md | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index 460a709..f889685 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -749,6 +749,16 @@ do. Read them before writing anything that touches the same mechanism. core at 131 MB/s. Splitting there also means no key leaves the node's own process +- **A transfer capped with no core busy and no loss in the log: read the + kernel's drop counter on the receiving machine.** Uploads ran at 6.5 MB/s. + The chunk handler was timed (0.7 ms a chunk, 30 % of the time), the window + the node advertises was read (1 MB), and neither was it. `nstat -az | grep + RcvbufErrors` before and after one upload was: 2460 datagrams dropped at the + node's own socket. Same cause as downloads, mirrored, and the node's log + cannot show it because the sender that backs off is the browser. A 4 MB + socket buffer gave 19.5 MB/s (`udp_buffer.py`); it needs + `net.core.rmem_max` raised on a default machine + ### More of the same, from four rounds of live testing - **A protocol harness cannot test the SPA.** Any second implementation of the -- cgit v1.2.3