From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-11-iad.dyndns.com (mxout-059-iad.mailhop.org [216.146.32.59]) by lists.bufferbloat.net (Postfix) with ESMTP id C77A02E0188 for ; Wed, 2 Feb 2011 08:29:21 -0800 (PST) Received: from scan-12-iad.mailhop.org (scan-12-iad.local [10.150.0.209]) by mail-11-iad.dyndns.com (Postfix) with ESMTP id 2CE8B171356 for ; Wed, 2 Feb 2011 16:29:20 +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-11-iad.dyndns.com (Postfix) with ESMTP id 4869C171347 for ; Wed, 2 Feb 2011 16:29:18 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:2:21c:25ff:fe80:46f9]) (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 899B55E863 for ; Wed, 2 Feb 2011 09:29:17 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 0838C122143; Wed, 2 Feb 2011 09:29:16 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Justin McCann Organization: Teklibre - http://www.teklibre.com References: <87bp2upinw.fsf@cruithne.co.teklibre.org> Date: Wed, 02 Feb 2011 09:29:16 -0700 In-Reply-To: (Justin McCann's message of "Wed, 2 Feb 2011 11:05:04 -0500") Message-ID: <877hdipfhf.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 Cc: bloat Subject: Re: [Bloat] TCP vegas vs TCP cubic 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: Wed, 02 Feb 2011 16:29:22 -0000 Thx for the feedback. I've put up more information on the wiki at: http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_TCP_cubic_vs_TC= P_vegas (At least netnews had a "C"ancel message option. Wikis are safer to use before your first cup of coffee) Justin McCann writes: > On Wed, Feb 2, 2011 at 10:20 AM, Dave T=C3=A4ht wrote: >> Can I surmise that TCP cubic is like a dragster, able to go really fast >> in one direction down a straightaway, and TCP vegas more like an 80s >> model MR2, maneuverable, but underpowered? > > There are some parameters to tune, essentially setting the number of > packets you want queued in the network at any one time (see > http://neal.nu/uw/linux-vegas/). I haven't messed with it much myself, > but you might try to increase those just a bit -- if Vegas I am reading now. > underestimates the queue size and the queue empties, you'll never get > the throughput. Ideally there would always be exactly one packet in > the bottleneck queue. What a happy day that would be. > > But I think your results are pretty much expected with Vegas, since it > uses the increase in queuing latency as an early congestion indicator. > If everyone used it, we may be better off, but other congestion > algorithms aren't fair to Vegas since they wait until there are packet > drops to notice congestion. My thought was, is that if it were possible that the wireless side of a given stack used it, life might be better on that front. Ultimately. For people that upload stuff. >> On a failed hunch, I also re-ran the tests with a much larger >> congestion window: > I think you mean larger send/receive buffers instead of congestion > window? I'll bet the Vegas parameters are keeping the congestion Correction noted. Coffee needed. > window smaller than your send/receive buffer sizes, so they aren't > limiting you in the first place, so no improvement. I'll take a packet trace next time I run the test. > > The web100 patches (web100.org) are great for getting into the details > of how TCP is working. If you don't want to apply them yourself, you > can try the Live CD of perfSONAR-PS (http://psps.perfsonar.net/). It > might be useful to have an NDT > (http://www.internet2.edu/performance/ndt/) server running on your > home network, or use one at M-Lab. It doesn't need much resource-wise > but the web100 patches. Excellent suggestions. Building now. (It seems to want java and I don't think the little clients I have on this testbed can handle that well) At the moment my little testbed is fairly flexible and my queue of things to test is quite large. I have bloat-reducing patches for all the devices in the picture except for the laptop's , which is proving to be painful to look at. At the moment, I'd like to be getting, useful, interesting, *repeatable* results for a variety of well defined latency + throughput tests with... stock firmware and then be able to re-run the interesting series(s) against more custom configurations. I've only deployed the first patch on the wndr3700 thus far. It was *amazing*.=20 > > Justin --=20 Dave Taht http://nex-6.taht.net