General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: brouer@redhat.com, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] how much delay is too much delay
Date: Fri, 13 Jan 2017 12:30:20 +0100	[thread overview]
Message-ID: <20170113123020.4361c60c@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1701131007060.31101@uplift.swm.pp.se>


On Fri, 13 Jan 2017 12:02:00 +0100 (CET) Mikael Abrahamsson <swmike@swm.pp.se> wrote:

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

(watched the video)
I love the way he measures the delay by recording the screen with a
high speed camera, and then correlate mouse-button activation by a
visual red-blink (some PC-local setup/app) and counting the frames
until the movement happen in the game.


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


-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

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

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-13 11:02 Mikael Abrahamsson
2017-01-13 11:30 ` Jesper Dangaard Brouer [this message]
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=20170113123020.4361c60c@redhat.com \
    --to=brouer@redhat.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=swmike@swm.pp.se \
    /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