Stream density: decide pass or fail on frames processed divided by measurement time

[jcork-intel]

What we are asking for

Replace the per-stream percentile with frames processed during the measurement phase, divided by
the duration of that phase. Compare that value against the target.

Acceptance criteria

1. The pass decision uses frames processed during the measurement phase divided by its duration.
2. The value used in the decision is the value written to the result.
3. Re-running the ASC detect and classify config on the same hardware produces a stream count
   whose reported rate can be reconciled against the raw log.

---

Context

How the current statistic got there

stream_density.py:1080-1084 sorts each stream's per-second readings and takes
the value at the 90th percentile by nearest rank. That value is what gets compared against the
target. The 90th percentile sits near the fastest reading a stream produced, so the gate reads
the top of the range.

That statistic arrived in c60a3db on 29 Jul 2026, merged as PR #240 under the title "Update
stream_density.py" with the template unfilled and no linked issue. It replaced
statistics.median, which had been added three weeks earlier in 7a058cb on 8 Jul 2026. The
commit changed the statistic only where the pass decision is made. The code that sizes the next
increment still uses the median, at stream_density.py:790, where the variable is still called
robust_per_stream.

We cannot find a recorded rationale for the change, which is the main reason this is being
raised. If there was one, we would like to hear it before anything is altered.

What we measured internally

We ran the ASC detect and classify config with shipped defaults and reduced the same run three
ways: frames divided by measurement time, the middle of the range, and the 90th percentile.

The aggregate rate and the middle of the range both fall away from the target as streams are
added. The 90th percentile does not, because the spread widens under load while its top edge
stays where it is. So the gate is reading the part of the distribution that does not respond to
load, and it certifies a density at which a large share of streams are below the pass mark.

Figures are available to the team internally rather than here.

What the standards do

No major suite gates throughput on a percentile of short-window samples.

Suite	How throughput is defined	Where percentiles are used
MLPerf Inference	Offline reports samples per second over the run; Server reports the maximum sustainable rate under a latency bound	Latency only, p90 or p99, taken from the high end
TPC-C	Transactions completed during the measurement interval, divided by its elapsed time	Response time, as a separate constraint
SPEC (sfs, jbb, web)	Operations completed during a fixed measurement phase, divided by its duration, after a fixed warm-up	Response time, as a separate constraint
OpenVINO benchmark_app	Frames processed divided by total execution time	Latency, reported as median, average, min and max
NVIDIA DeepStream	Frames processed divided by elapsed measurement time, as a running average	Not used for channel density

The fourth row is the one that bites. Intel's own toolkit, shipped with the runtime this
pipeline already uses, computes throughput as frames divided by execution time. A partner
running both tools will see two different definitions coming from Intel.

MLPerf takes its latency percentile from the high end because high latency is the bad outcome.
Applying that reasoning to frame rate points at the low end, since low throughput is the bad
outcome. The aggregate rate avoids the question, and every suite above already uses it.

A second benefit

Counting whole frames inside one-second windows means a window sometimes catches one frame more
or fewer than expected. On a 15 fps source that produces readings of 14, 15 and 16 around a true
mean of exactly 15. Counting over the whole measurement phase removes the artifact rather than
smoothing it.

Related

Depends on nothing. Changes a published number, so it should land before the next set of
results goes out.

---

Line references link to performance-tools @ 144d3b6 and loss-prevention @ f865f5b, read 31 Aug 2026.