From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-24-ewr.dyndns.com (mxout-037-ewr.mailhop.org [216.146.33.37]) by lists.bufferbloat.net (Postfix) with ESMTP id DFF662E015C for ; Sat, 12 Mar 2011 07:58:13 -0800 (PST) Received: from scan-21-ewr.mailhop.org (scan-21-ewr.local [10.0.141.243]) by mail-24-ewr.dyndns.com (Postfix) with ESMTP id AA19D5D46DF for ; Sat, 12 Mar 2011 15:58:12 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-24-ewr.dyndns.com (Postfix) with ESMTP id E29AB5D46A8 for ; Sat, 12 Mar 2011 15:58:08 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id 6B40F5E9D0 for ; Sat, 12 Mar 2011 08:58:08 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 6516E120848; Sat, 12 Mar 2011 08:58:07 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: bloat@lists.bufferbloat.net Organization: Teklibre - http://www.teklibre.com References: <87sjv1bj50.fsf@cruithne.co.teklibre.org> Date: Sat, 12 Mar 2011 08:58:07 -0700 In-Reply-To: (John Carmack's message of "Fri, 11 Mar 2011 21:46:02 +0000") Message-ID: <8762rol4a8.fsf_-_@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] Bufferbloat and Internet gaming X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 15:58:14 -0000 John Carmack (of armadillo aerospace[2] and idsoftware fame) gave me permission to repost from this private email... John Carmack writes: > I would really like to help, but I don't know of a good resource for > you [for 3D visualizations of bufferbloat]. If I could clone myself a > couple times, I would put one of them on the task... > > Buffer bloat was a huge issue for us back in the modem days, when we > had to contend with multiple internal buffers in modems for data > compression and error correction, on top of the serial buffers in the > host. Old school modem players generally have memories of "surge > lag", where things were going smoothly until the action spiked and the > play could then get multiple seconds of latency backed up into > buffers. > > I had always advocated for query routines on the local host, because I > would choose to not send a packet if I knew it was going to get stuck > in a bloating buffer, but this has been futile. There is a strong > aversion to wanting to add anything at the device driver level, and > visibility at the OS level has limited benefits. Just the last year I > identified some bufferbloat related issues on the iPhone WiFi stack, > and there was a distinct lack of enthusiasm on Apple's part to wanting > to touch anything around that. > > A point I would like to add to the discussion: > > For continuously updating data streams like games, you ideally want to > never have more than one packet buffered at any given node, and if > another packet arrives it should replace the currently buffered packet > with the same source/dest address/port while maintaining the original > position in the transmit queue. This is orthogonal to the question of > fairness scheduling among multiple streams. Unfortunately, I suspect > that there are enough applications that mix latency sensitive and bulk > data transfer on the same port that it would be problematic to > heuristically implement this behavior. Having an IP header bit asking > for it would be ideal, but that seems unlikely to fly any time soon... > > I am a little doubtful of the real world benefits that can be gained > by updating routers at end user sites, because the problem is usually > in the download direction. A poster child case could be created with > playing a game while doing a backup to a remote system, but that case > should be much less common than multiple people in your house > streaming video while you are playing a game. If you do see some good > results, I would be interested in hearing about them and possibly > helping to promote the results. > > John Carmack > > > -----Original Message----- > From: Dave T=C3=A4ht [mailto:d@taht.net]=20 > Sent: Saturday, March 05, 2011 10:57 AM > To: John Carmack > Subject: Bufferbloat and 3D visualizations > > > Dear John: > > Thx for the retweet the other day. I know you're a really busy guy, but... > > Really high on our list (as network guys, not graphics guys) is > finding someone(s) that can turn the massive amounts of data we're > accumulating about bufferbloat into a visualization or three that can > show the dramatic impact bloat can have for latency under load for > voip and gaming. > > If you know anyone, please forward this mail. > > When I "see" bufferbloat, I see something like gource's visualization > of commit history: > > http://www.thealphablenders.com/2010/10/new-zealand-open-source-awards/ > > - the bloated devices in the path exploding in size as the bottleneck > moves, and exploding as the buffers are overrun. > > I also see (dynamically) stuff like this, with the vertical bars > growing past the moon on a regular basis: > > http://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography//atlas= /geographic.html > > We released a debloat-testing[1] tree the other day, which uses the > eBDP algorithm for rate control on wireless and incorporates the CHOKe > and SFB AQMs. It's far from fully baked as yet, but is quite > promising. > > In addition to jg's now well known TCP traces, I'm in the process this > week of collecting RTP traces (VOIP) which is a lot easier to look at > than TCP's methods of ramping up and down. There are those in the > network business that think 40ms latency and jitter are ok... :( > > I'm also pretty interested in the structure of how (for example) quake > packets do timestamps and how quake compensates for latency and packet > loss. (Minor update from a followup mail - quake used to mix and match but John now recommends bulk transfers be done via TCP. I am thinking ccnx or ledbat are possible better alternatives at the moment) > > But I'm totally graphically untalented. > > -- > Dave Taht > http://nex-6.taht.net > > [1] https://lists.bufferbloat.net/pipermail/bloat-devel/2011-February/000= 061.html > > Ad astra per aspera! [2] http://www.armadilloaerospace.com/n.x/Armadillo/Home/Gallery/Videos --=20 Dave Taht http://nex-6.taht.net