From 3bf5972dd418c23ecf98695fbf8c5f763a2109ef Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Fri, 16 Oct 2026 12:28:25 +0200 Subject: docs: one datagram per turn of the loop on Windows, and how it hid Co-Authored-By: Claude Opus 5.5 --- CLAUDE.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index dfcb0ed..4c7c983 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -772,6 +772,18 @@ do. Read them before writing anything that touches the same mechanism. `sctp_fix.py`: 39 MB/s, the node at 49. No amount of reading our code finds a quadratic loop in a dependency; one profile does +- **A ceiling that falls as the loop gets busier is not a CPU ceiling.** + Windows downloads stayed slow with no core saturated: the node at 45 % of a + core, 9 MB/s over eight connections, and an SCTP round trip of 745 ms on + loopback, which is a queue, not a wire. The ProactorEventLoop's datagram + transport sends one datagram per turn of the loop and reads one, each through + an overlapped operation (42 % of a connection process was + `IocpProactor.sendto`), so every other thing the loop does slows every + connection. Linux sends straight from the socket. `proactor_udp.py` does the + same on Windows; a benchmark only showed it once its loop had other work to + do, because an idle loop turns fast enough to hide it. When a transfer is slow, compare the round trip SCTP reports with the + real one before profiling: a large gap is a queue in this process + - **A default of "off" ships a feature nobody has.** `connection_processes` defaulted to 1, which starts no process: the multi-core path was measured at 131 MB/s and reached by no node whose operator had not found the setting, so -- cgit v1.2.3