https://gitlab.synchro.net/main/sbbs/-/commit/18d358405a119dcd3bc91d4a
Modified Files:
exec/load/ircd/core.js
Log Message:
ircd: restore the intended 4-commands-per-2-seconds client rate
Recvq_Unthrottle() resumed each new window at num_sent = 3, one below the cap Process_Recvq() throttles on, so every window after the very first admitted a single command and then re-throttled for 2000ms. The sliding window in Process_Recvq() is written for 4 commands per 2 seconds; clients have been getting one per 2 seconds -- a 4x under-run -- since the throttle arrived in d7cb93923c (wave-27-oops), "IRCd 1.9b".
Start the new window empty instead.
The old rate did more than slow clients down. Anything sustaining more than
0.5 commands/second built an unbounded recvq backlog, and once that backlog passed MAX_CLIENT_RECVQ (2560 bytes, exec/ircd.js) the client was killed for "Excess Flood" -- at traffic well under what the throttle was written to permit. Vertrauen's own GitLab announcement hook tripped exactly that on 2026-07-21 at 02:35:18 (2646 bytes) while pacing itself at one message per 700ms. Worse, the recvq is drained by a timer and outlives the socket, so the server kept relaying the dead client's backlog for another seven minutes, drawing a "non-existent origin" KILL from every peer for each relayed
message, and the hook logged a send error for every message it still had to write.
Measured by driving the real Recvq_Unthrottle()/Process_Recvq() out of this file on a virtual clock, with a continuously-backlogged queue: 1.11 commands per 2s window before, 4.44 after.
MAX_CLIENT_RECVQ is deliberately left alone -- it is the actual flood guard, and it starts doing its job correctly once the drain rate is right.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)