Re: [Bloat] TCP vegas vs TCP cubic

[Jim Gettys <jg@freedesktop.org>]

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"<rscheff@gmx.at>  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""<d@taht.net>
>> To: "Justin McCann"<jneilm@gmail.com>
>> Cc: "bloat"<bloat@lists.bufferbloat.net>
>> 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<jneilm@gmail.com>  writes:
>>>
>>>> On Wed, Feb 2, 2011 at 10:20 AM, Dave Täht<d@taht.net>  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
>>>
>>
>