From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-iad.dyndns.com (mxout-068-iad.mailhop.org [216.146.32.68]) by lists.bufferbloat.net (Postfix) with ESMTP id DF4272E0354 for ; Thu, 3 Feb 2011 10:35:10 -0800 (PST) Received: from scan-02-iad.mailhop.org (scan-02-iad.local [10.150.0.207]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id DBF738337DB for ; Thu, 3 Feb 2011 18:35:10 +0000 (UTC) X-Spam-Score: -4.0 (----) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 128.30.2.149 Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id 88F49833810 for ; Thu, 3 Feb 2011 18:35:09 +0000 (UTC) Received: from 30-25-212.dynamic.csail.mit.edu ([128.30.25.212]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Pl41B-0001sK-Ox for bloat@lists.bufferbloat.net; Thu, 03 Feb 2011 13:34:57 -0500 Message-ID: <4D4AF551.1030801@csail.mit.edu> Date: Thu, 03 Feb 2011 13:34:57 -0500 From: Seth Teller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 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> <4D49B824.5090900@freedesktop.org> In-Reply-To: <4D49B824.5090900@freedesktop.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: Thu, 03 Feb 2011 18:35:11 -0000 For completeness, are the commands needed to undo netsh int tcp set global congestionprovider=ctcp netsh int tcp set global ecncapability=enabled these: netsh int tcp set global congestionprovider=tcp netsh int tcp set global ecncapability=disabled ? On 2/2/2011 3:01 PM, Jim Gettys wrote: > 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 >>>> >>> >> > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat