I've installed and been using Cardwell's TCP-Vegas
algorithm in 2.2.10. I saw a mention on the list
a few weeks ago and followed the link to:
http://www.cs.washington.edu/homes/cardwell/linux-vegas/
Since then, I haven't seen much more on the subject.
Although the patch was not specific to 2.2.10, it patched
and compiled easily, and worked right out of the box. No
fuss, no muss....
I have lived with the Linux-Vegas patch now for 2
weeks. My observations suggest that the Vegas congestion
avoidance algorithm (as implemented by Cardwell, _et al_)
outperforms the present 2.2.10 ipv4 algorithm on both
a 28.8 K dialup connection and on a more conventional
LAN workstation.
I made my observations based on data rate observed on
Xosview, the indicated transfer speed reported by Netscape,
and a pair of Calibrated Eyeballs (TM).
For the "home" setup, I had a 28.8K modem with hardware
MNP-5 compression, and hardware error correction. I
disabled ppp_deflate, and used V-J header compression.
The MRU/MTU values for the link were the default values
for my ISP (MRU=1524, MTU=384, IIRC). The DCE baud rate
for the 28.8K dialup modem (ttyS1) was set at 115KB for
all tests.
For the "office" test, I had available a PPRO quad fitted
with a 3C905B ether card running at 100 MBps, half-duplex.
The MTU/MRU values were left at kernel defaults. Both
systems had a stock RH6.0 distro + monolithic kernel 2.2.10
installed.
I observed the following:
1. With the present TCP algorithm, long FTP downloads
at 28.8 KBps always started at a high burst rate,
approaching 5-6 KBps. Within a few seconds there
was always a several-second stall, followed by a
gradual recovery to about 2.2-2.7KBps. In practice,
the indicated DTE rate I saw on XOsview fluctuated
wildly. The only work-around that seemed to have any
effect was to reduce the MRU to 384 bytes, and to reduce
the MNP-5 block size to 64 bytes. It was as though
there was an "invisible wall" at 2.7 KBps that just
could *not* be exceeded. Even at an MRU of 512, momentary
delays occurred every 6*1024 bytes. This could be seen
easily with Xosview and also with "#hash on" in ftp
sessions. These data rates are based on "gzipped" data.
I spent considerable time over the last year trying
different modem settings (compression, MNP max_block_size,
and MRU) combinations. I was never able to stream at
rates exceeding 2.7KBps.
2. Under the same conditions as (1), with the TCP-Vegas
algorithm enabled:
( echo 1 > /proc/sys/net/ipv4/tcp_vegas_cong_avoid )
the dial up connection now appears rock-steady steady on
Xosview, and there are very few retransmits. The MRU
setting appears to have little effect on the performance
of the link. I am now able to regularly achieve sustained
ftp rates of 2.9-3.1 KBps on a long download. There are
no stalls. The download rate starts at about 3.5-4 KBps
and drifts slowly down to about 3.1 KBps. These rates
are typical when downloading gzip'ped or image file
transfers, which are relatively uncompressable. I can
get 8-10KBps rates on text-only downloads.
3. On the "office" setup, using a 3Com3C905B, at 100MBps
(half-duplex) the present 2.2.10 is nearly unusable
for web browsing. It is worth noting that the load
on our office LAN is what I would consider to be
"severely congested". I usually could not get web page
transfer rates above a few KBps, and occasionally,
the link would degrade to a few hundred *bytes* per
second (as indicated by Netscape.) All ether* para-
meters were left at the kernel defaults.
4. By enabling the Vegas-linux congestion patch on the
"office" machine (LAN connection), I now am able to get
into the 10 KBps range regularly, during the worst
times of the day. The overall performance of the
office box is now at least as good as, if not better
than the best our $$$$ workstations. The "office"
machine is a PPro 200 quad (Goliath II from American
Megatrends).
In summary, the performance improvements I have seen with
Cardwell/Bak's TCP_vegas_cong_avoid algorithm have improved
the performance of the kernel's packet processing algorithm
to Windows-like levels (one of the few things M$ appears to
have done well at). The subjective "feel" of the box is much
snappier now, even on the dial-up connection.
FWIW, I occasionally see code snippets from net/ipv4 flying
around on the beowulf-list that appear to be related to the
network stack. I infer that the beowulf folks are tinkering
with the IPV4 algorithms as well???
I believe the Vegas-linux congestion avoidance algorithm
would be a worthwhile improvement. I'm curious as to whether
Cardwell's Vegas implementation will become part of 2.4.x.
Or, perhaps, I should ask whether there is a relevant RFC-*
that would be "broken" by this algorithm. I'll be pleased to
contribute any additional testing anyone may be interested in.
Warm regards,
Paul
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Reich reichp[at]ameritech.netQ: How many Harvard MBA's does it take to screw in a lightbulb?
A: Just one. He grasps it firmly and the universe revolves around him.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/