Re: [Bloat] Updated Bufferbloat Test

[Sebastian Moeller <moeller0@gmx.de>]

Hi Sina,

let me try to invite Daniel Lakeland (cc'd) into this discussion. He is doing tremendous work in the OpenWrt forum to single handedly help gamers getting the most out of their connections. I think he might have some opinion and data on latency requirements for modern gaming.
	@Daniel, this discussion is about a new and really nice speedtest (that I already plugging in the OpenWrt forum, as you probably recall) that has a strong focus on latency under load increases. We are currently discussion what latency increase limits to use to rate a connection for on-line gaming

Now, as a non-gamer, I would assume that gaming has at least similarly strict latency requirements as VoIP, as in most games even a slight delay at the wrong time can direct;y translate into a "game-over". But as I said, I stopped reflex gaming pretty much when I realized how badly I was doing in doom/quake.

Best Regards
	Sebastian


> On Feb 25, 2021, at 21:01, Sina Khanifar <sina@waveform.com> wrote:
> 
>> [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.

	That would be great, one of the nicest features of the dslreports test is the high resolution bufferbloat measurement. But since you mention CPU issues, I have the impression that the HR probes on dslreports occasionally show spikes that might be more related to the browser and endhosts CPU than to the router; that said the bulk of the probes seem to be dominated by the router.

> 
> 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.

	I hope Daniel will chime in, other than that, purely based on gut-feeling, I think 95% makes sense for a reaction gated applications?

Best Regards
	Sebastian


> 
> On Thu, Feb 25, 2021 at 2:51 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Hi Sina,
>> 
>> 
>>> On Feb 25, 2021, at 06:56, Sina Khanifar <sina@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