Messages in this thread | | | Date | Tue, 3 Aug 1999 13:43:36 +0800 (CST) | From | "Rodel T. Viado" <> | Subject | Re: Vegas_cong_avoid patch redux (was Re: TCP Vegas Patch) LONG |
| |
Hi all,
same here I with our dial-up server and proxy server, transfer rates seems to be doing better with TCP Vegas comapred with the current TCP in 2.2.10
Rodel
On Mon, 2 Aug 1999, paulr wrote:
> 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/ >
- 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/
| |