From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C71663B2A3 for ; Fri, 13 Jan 2017 06:30:24 -0500 (EST) Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 129EA1831; Fri, 13 Jan 2017 11:30:25 +0000 (UTC) Received: from localhost (ovpn-200-24.brq.redhat.com [10.40.200.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9F88D74A10; Fri, 13 Jan 2017 11:30:23 +0000 (UTC) Date: Fri, 13 Jan 2017 12:30:20 +0100 From: Jesper Dangaard Brouer To: Mikael Abrahamsson Cc: brouer@redhat.com, bloat@lists.bufferbloat.net Message-ID: <20170113123020.4361c60c@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 13 Jan 2017 11:30:25 +0000 (UTC) Subject: Re: [Bloat] how much delay is too much delay X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 11:30:24 -0000 On Fri, 13 Jan 2017 12:02:00 +0100 (CET) Mikael Abrahamsson 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