A new TCP Vegas patch for 2.2.10/2.3.10 is available at:
This page also has some notes on enabling and configuring this
implementation, as well as traces and benchmark results. The benchmark
results indicate Vegas can help for low-bandwidth-delay paths like DSL
where the sender is constantly over-running buffers, or
high-bandwidth-delay WAN paths where the receiver isn't sending SACKs and
the sender is wasting a lot of time recovering from losses.
You may remember that 2.1 had a Linux implementation that was removed
after 2.1.91, due to performance problems, i gather. Our
implementation is unrelated to that 2.1.x implementation (except,
obviously, that they're both Vegas implementations :-), and makes
several critical improvements over that earlier Vegas implementation:
o use of fine-grained time stamps (10ms-granularity doesn't cut it)
o careful filtering and accounting to cope with delayed ACKs.
o speedier slow-start due to increasing cwnd every RTT,
just like traditional TCP congestion control
>From looking at the older Vegas implementation, i'd guess that these
fixes address many of the performance problems in that implementation.
Other fixes and enhancements are described on the web page.
I'd love to get any feedback people have on the code or performance
results people see from Vegas.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/