Latency as a first-class constraint in (LP+ASC) stream density decisions

[sumanaga]

As a
Performance engineer running pipeline density benchmarks

I want
The stream density algorithm to consider both FPS and latency when deciding whether to increase, hold, or decrease pipeline count

So that
The reported maximum stream density reflects sustainable real-time performance, not just throughput

Business Value
Improves benchmark trust by preventing high-density results that meet FPS but violate latency expectations

Requirements

1. The density decision must include latency thresholds in addition to FPS thresholds.
2. A pipeline count is considered passing only when both conditions are true:
3. FPS condition: all streams meet configured FPS pass criteria.
4. Latency condition: latency metric stays within configured latency limit.
5. If FPS passes but latency fails for consecutive windows, density must not increase and should enter decrement logic.
6. Latency checks must support hysteresis (pass and fail bands) to avoid oscillation.
7. Latency thresholds must be configurable through environment variables and CLI-compatible configuration.
8. Final reported max density must be the highest stable pipeline count that satisfies both FPS and latency criteria.

Acceptance Criteria

1. Given stream density mode is running, when FPS passes and latency passes for required consecutive windows, then pipeline count may increase.
2. Given stream density mode is running, when FPS passes but latency exceeds fail threshold for configured consecutive windows, then pipeline count decreases.
3. Given stream density mode is running, when latency is between pass and fail thresholds, then pipeline count is held (no increase/decrease) until window criteria is met.
4. Given final density is reported, then the output clearly states FPS status and latency status used for the decision.
5. Given latency-aware mode is enabled, then max density must never be reported from a state where latency failed.
6. Given latency metrics are unavailable or invalid for a window, then that window is treated as non-pass and logged with reason.

Configuration Parameters

LATENCY_TARGET_MS
LATENCY_HYSTERESIS_MS
LATENCY_CONSECUTIVE_FAIL_WINDOWS
LATENCY_CONSECUTIVE_PASS_WINDOWS
LATENCY_MODE with values required or advisory (default required)

Definition of Done

1. Density decision logic includes latency gating and hysteresis.
2. Logs include per-iteration FPS decision, latency decision, and resulting action.
3. Documentation updated with latency-aware decision rules and configuration examples.