Swept QUIET_WINDOW from 20 to 60 microseconds on branch quiet-sweep, benched against main:
- linux-x64-1cpu-1gb: writes plus 9.6 percent, write p99 11.39 to 6.55 ms
- linux-x64-full: plus 11.2 percent, p99 4.14 to 1.96 ms
- linux-arm64-full: minus 3.1 percent
- linux-x64-2cpu-2gb: minus 31.9 percent, p99 1.28 to 2.46 ms
- windows-x64-full: minus 24.3 percent
The prediction for the single core profile held exactly: it wanted a longer window, recovered the 6.9 percent it lost when the window was introduced, and nearly halved its write p99. But the same value costs the two core and Windows profiles badly, so no single constant is right. Left unmerged.
What this says is that the window should track how long writers actually take to arrive rather than being configured. An arrival-interval estimate, something like the observed gap between the first and last request of recent groups, would set itself per machine. A previous attempt to close the group once it matched the previous group size failed with a surfaced WriteConflict and needs retesting on a machine where the retry budget is not being starved by a full disk.
Swept QUIET_WINDOW from 20 to 60 microseconds on branch quiet-sweep, benched against main:
The prediction for the single core profile held exactly: it wanted a longer window, recovered the 6.9 percent it lost when the window was introduced, and nearly halved its write p99. But the same value costs the two core and Windows profiles badly, so no single constant is right. Left unmerged.
What this says is that the window should track how long writers actually take to arrive rather than being configured. An arrival-interval estimate, something like the observed gap between the first and last request of recent groups, would set itself per machine. A previous attempt to close the group once it matched the previous group size failed with a surfaced WriteConflict and needs retesting on a machine where the retry budget is not being starved by a full disk.