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