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 <noreply@anthropic.com>

1 files changed, 10 insertions, 0 deletions

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