From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-22-ewr.dyndns.com (mxout-134-ewr.mailhop.org [216.146.33.134]) by lists.bufferbloat.net (Postfix) with ESMTP id 17B742E0188 for ; Wed, 2 Feb 2011 12:01:45 -0800 (PST) Received: from scan-21-ewr.mailhop.org (scan-21-ewr.local [10.0.141.243]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id 6A2DF32BCB for ; Wed, 2 Feb 2011 20:01:45 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 76.96.62.48 Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id E082C3212D for ; Wed, 2 Feb 2011 20:01:41 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id 37yX1g00A1YDfWL5581itG; Wed, 02 Feb 2011 20:01:42 +0000 Received: from [192.168.1.119] ([98.229.99.32]) by omta20.westchester.pa.mail.comcast.net with comcast id 381h1g01F0hvpMe3g81iqg; Wed, 02 Feb 2011 20:01:42 +0000 Message-ID: <4D49B824.5090900@freedesktop.org> Date: Wed, 02 Feb 2011 15:01:40 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <87bp2upinw.fsf@cruithne.co.teklibre.org> <877hdipfhf.fsf@cruithne.co.teklibre.org> <585FF290C0384319AA507AEF4BC8F3FB@srichardlxp2> <87y65ynt5g.fsf@cruithne.co.teklibre.org> In-Reply-To: <87y65ynt5g.fsf@cruithne.co.teklibre.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 20:01:46 -0000 On 02/02/2011 02:16 PM, Dave Täht wrote: > > Thx. Wiki'd: > > http://www.bufferbloat.net/projects/bloat/wiki/Windows_Tips > > Is there a windows equivalent of ethtool? Dunno what command line there may be. Certainly the device driver I looked at had a UI that would let me control the ring buffer size, IIRC from my November experiments on Windows. - Jim > > "Richard Scheffenegger" writes: > >> For all the Windows Vista / Windows 7 Users around, they can enable >> "Compound TCP", which is a Hybrid TCP Congestion Control approach: >> >> netsh int tcp set global congestionprovider=ctcp >> >> and, while you're at it, also enable ECN (lossless congestion control >> feedback): >> >> netsh int tcp set global ecncapability=enabled >> >> If enough End Users enable ECN, core providers may be inclined to >> deploy AQM with Packet Marking too... And as Home Gateways are those >> which are prone to ECN implementation bugs, a full disconnect from the >> internet (rather than certain sites not reachable) is quite easy to >> diagnose at that end. >> >> Been running with ECN since a couple of months, and so far I have yet >> to encounter a site that will consistently fail with ECN. Actually, >> enabling ECN gives you more retries with the SYN (3x ECN+SYN, 3x >> normal SYN), so in a heavy congested / bufferbloated environment, your >> small flows might get through eventually, with higher probability. >> >> Regards, >> Richard >> >> >> >> ----- Original Message ----- >> From: "Dave "Täht"" >> To: "Justin McCann" >> Cc: "bloat" >> Sent: Wednesday, February 02, 2011 5:29 PM >> Subject: Re: [Bloat] TCP vegas vs TCP cubic >> >> >>> >>> 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_TCP_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äht 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*. >>> >>>> >>>> Justin >>> >>> -- >>> Dave Taht >>> http://nex-6.taht.net >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>> >> >