[Bloat] Updated Bufferbloat Test

[Sina Khanifar]

> [SM] Maybe the solution would be to increase the frequency of the RTT measures and increase the quantile somewhat, maybe 90 or 95?

I think we scaled back the frequency of our RTT measurements to avoid
CPU issues, but I think we can increase them a little and then use
95th percentile latency with a cutoff of 400ms or so as the check vs
warning condition for videoconferencing, and VOIP.

We could also maybe use the 95th percentile cutoff for gaming? I'm not
sure what the limits/cutoff should be there, though. Would love some
suggestions.

On Thu, Feb 25, 2021 at 2:51 AM Sebastian Moeller <moeller0 at gmx.de> wrote:
>
> Hi Sina,
>
>
> > On Feb 25, 2021, at 06:56, Sina Khanifar <sina at waveform.com> wrote:
> >
> > Thanks for the feedback, Dave!
> >
> >> 0) "average" jitter is a meaningless number. In the case of a videoconferencing application, what matters most is max jitter, where the app will choose to ride the top edge of that, rather than follow it. I'd prefer using a 98% number, rather than 75% number, to weight where the typical delay in a videoconfernce might end up.
> >
> > Both DSLReports and Ookla's desktop app report jitter as an average
> > rather than as a max number, so I'm a little hesitant to go against
> > the norm - users might find it a bit surprising to see much larger
> > jitter numbers reported. We're also not taking a whole ton of latency
> > tests in each phase, so the 98% will often end up being the max
> > number.
> > [...]
>
> [SM] Maybe the solution would be to increase the frequency of the RTT measures and increase the quantile somewhat, maybe 90 or 95?
>
> Best Regards
>         Sebastian