From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-02-ewr.dyndns.com (mxout-236-ewr.mailhop.org [216.146.33.236]) by lists.bufferbloat.net (Postfix) with ESMTP id D93652E0354 for ; Thu, 3 Feb 2011 09:53:09 -0800 (PST) Received: from scan-02-ewr.mailhop.org (scan-02-ewr.local [10.0.141.224]) by mail-02-ewr.dyndns.com (Postfix) with ESMTP id 16A3D73D549 for ; Thu, 3 Feb 2011 17:53:09 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.43 Received: from mail-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by mail-02-ewr.dyndns.com (Postfix) with ESMTP id 49ADA73D378 for ; Thu, 3 Feb 2011 17:53:05 +0000 (UTC) Received: by ewy22 with SMTP id 22so817576ewy.16 for ; Thu, 03 Feb 2011 09:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QQ4LhGmpn8mHdY7e5GhfTJv3itX2pqfD1H8H5S+HIWs=; b=R2x8cMpKwkhqcTlkhmNcWlFnEyxfzawb72HA6X3mKVYYjnSI7oLIIP+HMXskmMZP0w 2sAsFZf9SxbzH5DfxjOHhGwUBWaukWSGWQwZUi2zX6KvuwLWaQ1ogWSswrXsH9ZMvFLI fknRfpD0jkNNVtFD21phfYzqm/onEf+rdZAA8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZKaca4yeT/Hd1qREDJfJja8ANz0DLzrlEGRsshawOyNJ14z2ra3WT5M503RxMCwrOZ C/jVnHGTLUszu5ETEuELJj+0and5MBuHwVjylZnB4l/swkJv3nL3rg55njOkBReZ2CYe jck6+GwUpJFkUGX/Pvit37yk++/WkpVLgr9ww= MIME-Version: 1.0 Received: by 10.204.52.134 with SMTP id i6mr3893074bkg.36.1296755584322; Thu, 03 Feb 2011 09:53:04 -0800 (PST) Received: by 10.204.73.207 with HTTP; Thu, 3 Feb 2011 09:53:04 -0800 (PST) In-Reply-To: References: <87bp2upinw.fsf@cruithne.co.teklibre.org> Date: Thu, 3 Feb 2011 10:53:04 -0700 Message-ID: From: Dave Taht To: Justin McCann Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 03 Feb 2011 17:53:10 -0000 re: vegas On Wed, Feb 2, 2011 at 9:05 AM, Justin McCann wrote: > 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 > 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. > > 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. After talking to the original author (who suggested that I also look at TCP veno) ... I suspect that Vegas is actually doing a *great* job measuring queuing latency, which is artificially high due to the network path under test doing 13 TX_Retries. I did some testing on a de-bloated device and vegas actually did slightly better than cubic (noted over on bloat-devel) but will need to either get my radio speed ratcheted down or update more radios to a de-bloated condition to test further. --=20 Dave T=E4ht