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 <[email protected]> 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 <[email protected]> wrote:
>>
>> Hi Sina,
>>
>>
>>> On Feb 25, 2021, at 06:56, Sina Khanifar <[email protected]> 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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
