1
0
Fork 0

docs(redos): the sweep now measures on the clock its own numbers justify

docs/redos-sweep.py timed on time.monotonic() while every ReDoS bound in the
suite had moved to process CPU time, so the 1.5 ms sensitivity floor and the
"~23 s at the cap" figure in docs/LIMITATIONS.md were produced by a different
instrument than the bounds they support. The script imports scan_seconds now.

Re-derived on that instrument, the floor came back UNCHANGED at 1.5 ms. Twelve
full runs of all 2585 arms: median ratio 1.95-2.03 in every size bucket above
50 us, but two-point excursions past the 2.6 threshold survive at every
magnitude (p99 2.9-3.3 even above 1 ms). Flagged arms per run by floor: 6.9 at
0.5 ms, 1.1 at 1.0 ms, 0.33 at 1.5 ms. Four arms flagged across the twelve runs,
each in exactly one; six arms that have ever flagged re-measure at exponent
0.97-1.09 over six doublings, at most 1.2 s at the cap. Descheduling was never
what made this sweep noisy -- a ratio from two points is.

Measured before publishing and it cost a correction: an earlier draft of this
change said the sweep "reports 0 candidates". The next run reported 2. Nine of
twelve instrumented runs are clean and eight consecutive shipped-script runs
under load flagged 0-3, so neither a clean run nor a flagged one is evidence
on its own -- the doc says that now.

Also corrects the pattern count in the same bullet: 150 -> 152, the script's
own printed total. The 0.3.4 CHANGELOG entry keeps its 150 as a snapshot.

No exported surface, no detector behaviour, no calibration touched.
802 passed, 129/129 classes, 6/6 gaps, 43 limitations, gitleaks clean.
This commit is contained in:
Kjell Tore Guttormsen 2026-08-18 16:56:01 +02:00
commit 74656123f9
3 changed files with 90 additions and 26 deletions

View file

@ -7,7 +7,26 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased]
Nothing yet.
### Changed — the ReDoS sweep now measures on the same clock as the bounds it justifies
`docs/redos-sweep.py` timed on `time.monotonic()` while every ReDoS bound in the
suite moved to process CPU time (`tests/redos_clock.py`), so the 1.5 ms
sensitivity floor and the "~23 s at the cap" figure published in
`docs/LIMITATIONS.md` came from a different instrument than the bounds they
support. The script now imports `scan_seconds` rather than timing itself.
The floor was re-derived on that instrument and **stayed at 1.5 ms**: over twelve
full runs of all 2585 arms the median ratio is 1.95-2.03 in every size bucket
above 50 µs, but two-point excursions past the 2.6 flag threshold persist at every
magnitude (p99 ratio 2.9-3.3 even above 1 ms) — 6.9 flagged arms per run at a
0.5 ms floor, 1.1 at 1.0 ms, 0.33 at 1.5 ms. Descheduling was never what made this
sweep noisy; a ratio computed from two points is. Four arms flagged across those
twelve runs, each in exactly one of them, and six arms that have ever flagged
re-measure at exponent 0.97-1.09 over six doublings — at most 1.2 s at the
1 000 000-char cap. The pattern count the script prints is 152, not the 150 of the
0.3.4 entry below; `docs/LIMITATIONS.md` now carries the current number.
No exported surface, no detector behaviour and no calibration changed.
## [1.1.0] — 2026-08-13