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
LatencyTuner
specifically and the overall receiver pipeline in different tests. This task describes tests forLatencyTuner
in isolation: check howLatencyTuner
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.LatencyTuner
into situations where: