What we are asking for
Change the INIT_DURATION default from 120 to 60, in stream_density.py:620 and in
loss-prevention loss-prevention Makefile:44. Leave it configurable for anyone who has a reason to wait longer.
Acceptance criteria
- The default is 60 seconds.
- The value is still overridable.
- The settle time used is stated in the run result.
- A sweep on the same hardware reaches the same stream count as it did with 120.
Context
What we found
INIT_DURATION is set to 120 seconds in two places: stream_density.py:619-620
supplies it when the environment does not, and loss-prevention sets the same value in
loss-prevention Makefile:44. Both have to move for the default to change for anyone running ASC out of that
repo. The wait is slept at stream_density.py:711 and paid again at every stream count on the
way up, so it is most of why a sweep takes as long as it does.
The 120 looks chosen rather than measured, so we measured it. Reading several hundred camera
streams across six runs on one test system, and looking for the point where each stream's
readings stop swinging:
| Wait |
Streams settled |
| 21 s |
50% |
| 35 s |
95% |
| 60 s |
99.3% |
| 120 s |
99.6% |
The extra 60 seconds buys 0.3%.
Why it matters
A sweep pays this wait once per stream count on the way up, so a long ramp pays it dozens of
times. Halving it takes a real bite out of every run, and the evidence says nothing is lost.
Line references link to performance-tools @ 144d3b6 and loss-prevention @ f865f5b, read 31 Aug 2026.
What we are asking for
Change the
INIT_DURATIONdefault from 120 to 60, in stream_density.py:620 and inloss-preventionloss-prevention Makefile:44. Leave it configurable for anyone who has a reason to wait longer.Acceptance criteria
Context
What we found
INIT_DURATIONis set to 120 seconds in two places: stream_density.py:619-620supplies it when the environment does not, and
loss-preventionsets the same value inloss-prevention Makefile:44. Both have to move for the default to change for anyone running ASC out of that
repo. The wait is slept at stream_density.py:711 and paid again at every stream count on the
way up, so it is most of why a sweep takes as long as it does.
The 120 looks chosen rather than measured, so we measured it. Reading several hundred camera
streams across six runs on one test system, and looking for the point where each stream's
readings stop swinging:
The extra 60 seconds buys 0.3%.
Why it matters
A sweep pays this wait once per stream count on the way up, so a long ramp pays it dozens of
times. Halving it takes a real bite out of every run, and the evidence says nothing is lost.
Line references link to
performance-tools@144d3b6andloss-prevention@f865f5b, read 31 Aug 2026.