From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-iad.dyndns.com (mxout-215-iad.mailhop.org [216.146.32.215]) by lists.bufferbloat.net (Postfix) with ESMTP id 572872E0188 for ; Wed, 2 Feb 2011 13:37:35 -0800 (PST) Received: from scan-01-iad.mailhop.org (scan-01-iad.local [10.150.0.206]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id F1AB48350A9 for ; Wed, 2 Feb 2011 21:37:34 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 213.165.64.23 Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mail-04-iad.dyndns.com (Postfix) with SMTP id 642BC834FF6 for ; Wed, 2 Feb 2011 21:37:34 +0000 (UTC) Received: (qmail invoked by alias); 02 Feb 2011 21:37:32 -0000 Received: from unknown (EHLO srichardlxp2) [213.143.107.142] by mail.gmx.net (mp063) with SMTP; 02 Feb 2011 22:37:32 +0100 X-Authenticated: #20720068 X-Provags-ID: V01U2FsdGVkX18ZjoBgK8wZYv7+m7IjaffX4gt08TIMKq+GduPpZP d+LjS4oIR05KTE Message-ID: From: "Richard Scheffenegger" To: =?utf-8?Q?Dave_=22T=C3=A4ht=22?= References: <87bp2upinw.fsf@cruithne.co.teklibre.org><877hdipfhf.fsf@cruithne.co.teklibre.org><585FF290C0384319AA507AEF4BC8F3FB@srichardlxp2> <87y65ynt5g.fsf@cruithne.co.teklibre.org> Date: Wed, 2 Feb 2011 22:36:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Y-GMX-Trusted: 0 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 21:37:35 -0000 I guess so, but only with limited tunables: Control Panel -> All Control Panel Items -> Network and Sharing Center -> Change Adapter Settings -> (Select Adapter, right click, Properties) Configure -> Advanced Then you get a list of things the driver allows to tweak (or at least show stuff). Interesting for us: Receive Buffers (256 on a Marvell Yukon) Transmit Buffers (256) Interrupt Moderation (also adds latency for slow flows). Regards, Richard ----- Original Message ----- From: "Dave "Täht"" To: "Richard Scheffenegger" Cc: "Justin McCann" ; "bloat" Sent: Wednesday, February 02, 2011 8:16 PM Subject: Re: [Bloat] TCP vegas vs TCP cubic Thx. Wiki'd: http://www.bufferbloat.net/projects/bloat/wiki/Windows_Tips Is there a windows equivalent of ethtool? "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 >> > -- Dave Taht http://nex-6.taht.net