2 Commits

Include renames

Author	SHA1	Message	Date
mrambossekandClaude Fable 5	3c9af04e6f	grant: replace the rate check with a token bucket ... The live throughput test found it: a 3-second run delivered 104 packets and stopped after 50 milliseconds. The rate check exempted the first 50 ms entirely, meaning to be lenient at startup. The effect was the opposite. A sender could dump an unbounded burst into that free window, and the instant the check switched on it compared those bytes against 50 ms worth of allowance and refused everything until real time caught up. Every short test passed — downtrain sends 50 packets, big_send seven — and every sustained send died about fifty milliseconds in. A token bucket (allowance = burst + rate x elapsed) has no such cliff; it is smooth from t=0. The burst is 100 ms of the allowed rate, floored at one ordinary datagram so a single packet is never refused outright. The floor is deliberately one datagram: at 8 kbps a 64 KB floor would be sixty-four seconds' worth, which is precisely the instant dump the ceiling exists to prevent. The existing rate test caught that when I first tried it, and it was right. Second half of the same bug: callers treated any refusal as terminal. TryAllow now says why, so a sender can pace through a transient "too fast just now" and still stop dead on a spent budget or an expired grant. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 14:10:30 +02:00
mrambossekandClaude Fable 5	3333788d9e	throughput: paced downstream rate, with the qualifier that makes it honest ... A throughput number reports the smallest limit on the path, and the sender's own ceiling is one of the candidates. If the server was asked for 50 Mbps and 50 Mbps arrived, the network was never the constraint and "50 Mbps" says nothing about it. So the result always carries limited_by and measures_network, and a finding is raised only when the path is actually implicated. Loss is computed against the *sender's* count, not the requested rate: the server reports what it put on the wire, and the gap is the loss. A receiver alone cannot tell "the network dropped it" from "the sender never sent it", and guessing turns a healthy server-side limit into a phantom network fault. The count is stored per action, not per packet — half a million packets of structs would turn a measurement into memory exhaustion. Sending is paced rather than flat out. An unpaced burst measures the server's NIC and the first queue it meets, then collapses into loss that reads as a network fault. The schedule is absolute rather than sleep-per-packet, which would accumulate scheduler error and drift the rate down over a ten-second run. Throughput gets its own grant budget sized from the request, so every other action stays bounded at 8 MiB. When the byte cap binds before the clock does, the *duration* is shortened and reported, rather than the run being truncated halfway: promising thirty seconds and delivering twenty-one is the same information with a surprise attached, and it keeps "the clock ended the run" as the normal case — the only case where the rate is a clean property of the path. That last behaviour came out of a test that failed honestly: 30 s at 100 Mbps needs 375 MB against a 256 MB cap. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 14:05:23 +02:00