docs: one datagram per turn of the loop on Windows, and how it hidHEADmain

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 12 insertions, 0 deletions

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