Messages in this thread | | | Date | Mon, 02 Aug 1999 23:58:56 -0500 | From | paulr <> | Subject | Vegas_cong_avoid patch redux (was Re: TCP Vegas Patch) LONG |
| |
Hi all!
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.net
Q: 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/
| |