General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: bloat@lists.bufferbloat.net
Subject: [Bloat] how much delay is too much delay
Date: Fri, 13 Jan 2017 12:02:00 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.02.1701131007060.31101@uplift.swm.pp.se> (raw)


https://www.youtube.com/user/xFPxAUTh0r1ty

This channel analyses several online games and how they work networkwise. 
It seems online games typically "tick" at 30-60Hz in that the game server 
and user application communicates this often. 60Hz seems to be the "golden 
standard", and I guess resolution of 17ms is fine for when things are 
happening.

In gaming they have multiple delay components, one is "input delay" which 
relates to the time it takes from you for instance press the mouse button, 
until the game shows that it has responded by showing you result on 
screen. It seems this is typically 40-60ms, because the game needs to 
handle the input, send data to the graphics card, which needs to render 
it, and then it needs to be sent to the monitor. There are of course a lot 
more than this, but you get the idea.

I don't know what the delay is from mouse-click to when the game knows you 
clicked, and then can send out this information to the game server, but 
from what I'm guessing from reading up on the topic, this is in the "less 
than 10ms" range. So theoretically, the game can send an update to the 
game server much quicker than it can display on the local screen.

Another data point for instance for the game "Rocket League", is that the 
highest ranking players have a hard time playing effectively when the 
user-to-game server "ping" is more than approximately 100ms. I don't know 
if this is RTT, but considering they're getting around 130ms from a user 
in Texas to a server in Europe, it seems reasonable that this is RTT.

My reason for bringing this up (again) in the bloat forum, is that these 
people are exactly the kind of people who are very sensitive to problems 
that "anti-bloat" solves. If we can come up with a solution that makes it 
less likely that these people will get "ping spikes" etc, and we can 
package up something that actually solves this (preferrably something they 
can go to the store and buy outright), this would be a great way to 
"market" it. I'm quite sure they'd be interested in making videos about it 
to make more people aware of the problem.

There are multiple "gaming routers" out there, with "QoS". I have no idea 
what this "QoS" does. If anyone knows, I'd be very interested in knowing 
more.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

             reply	other threads:[~2017-01-13 11:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-13 11:02 Mikael Abrahamsson [this message]
2017-01-13 11:30 ` Jesper Dangaard Brouer
2017-01-13 12:01   ` Mikael Abrahamsson
2017-01-13 23:00 ` Noah Causin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1701131007060.31101@uplift.swm.pp.se \
    --to=swmike@swm.pp.se \
    --cc=bloat@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox