I propose to test LatencyTuner specifically and the overall receiver pipeline in different tests. This task describes tests for LatencyTuner in isolation: check how LatencyTuner drives target latency depenging on incoming metrics.
Naturally we test here optimal latency estimation and the behavior of a state machine integrated into LatencyTuner in conjunction.
- In order to test latency estimation and decision making we could put
LatencyTuner into situations where:
- Decreasing is enabled iff current latency is significantly greater optimal latency estimation. Resulting target latency gets into --min/max-latency limits and it does not equal to optimal latency estimation, but conforms to a formula described in related comments in the source code.
- Increasing is enabled more or less immediately when it is needed, and resulting target latency gets into --min/max-latency limits.
- For state machine we check that transition happens if aforementioned conditions met and certain timeout passed.
- From the beginning up to startup timeout period no transition takes place
- Decreasing and Increasing could happen only from idle state and then specific timeouts should pass before transition back to idle state happens.
I propose to test
LatencyTunerspecifically and the overall receiver pipeline in different tests. This task describes tests forLatencyTunerin isolation: check howLatencyTunerdrives target latency depenging on incoming metrics.Naturally we test here optimal latency estimation and the behavior of a state machine integrated into
LatencyTunerin conjunction.LatencyTunerinto situations where: