/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */ Hey Everyone, I thought many of you would find this interesting if you are having slow Internet performance. Remember, this is a NON- Linus/AlanCox patch. --David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of paulr Sent: Monday, August 02, 1999 11:59 PM To: [EMAIL PROTECTED] 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. [snipped footer - it's repeated below] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of paulr Sent: Tuesday, August 03, 1999 8:30 PM To: [EMAIL PROTECTED] Cc: Andi Kleen Subject: Re: Vegas_cong_avoid patch redux (was Re: TCP Vegas Patch) LONG Andi Kleen wrote: > > [EMAIL PROTECTED] (paulr) writes: > > > 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. > > This sounds like you installed the Vegas patch on the > _receiver_. Correct? I'll assume so. ^^^^^^^^^^^^ Correct. > > > 1. With the present TCP algorithm, long FTP downloads -------------------<stuff snipped>---------------------- > > and MRU) combinations. I was never able to stream at > > rates exceeding 2.7KBps. > > Reality check: > Vegas only changes the TCP sending algorithms, nothing at the > receiver side (ACK policy is not changed). So for bulk downloads at > the receiver side it should make no difference. Did the sender in this > case run the Vegas algorithm too? Did it behave differently with > other senders not running Vegas? The web page I referred to in my posting suggested that the reimple- mented TCP_V_C algorithm performed better in the presence of *delayed ACKS* (ACK/NACK policy??). I take that to mean that the algorithm uses a different method of transmit/retransmit control when ACK/NACK link signals are time-delayed due to net.congestion. Cardwell mentioned in his paper that a part of the improvement resulted from the use of usleep() for a more finely-grained timing algorithm. Cardwell stated to the effect that a previous kernel implementation of Reno-Vegas did not achieve its potential because of the rather coarse granularirty of the 10ms (1 jiffy???) "clock tick" that was used.... I invite the interested reader to look at the paper which is published at: http://www.cs.washington.edu/homes/cardwell/linux-vegas/ The (indirect) quote above appeared on the first page, IIRC. > > > 2. Under the same conditions as (1), with the TCP-Vegas > > algorithm enabled: > > ----------------<stuff snipped>------------------- > > no stalls. The download rate starts at about 3.5-4 KBps > > If this is only on the client this sounds bogus. ??? > > > 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. > > Strictly it would break RFC1122 which requires VJ, but this could ^^^^^^^^ Isn't Van-Jacobsen a header compression algorithm? (I haven't read RFC-1122...) > probably be overcome. The problem is that Vegas has not been > extensively investigated yet on larger scale, what would happen > if millions of Linux 2.4 Vegas boxes in 2001 cause congestion > collapse on the internet ... ? [ok, this is a worst case scenario > and not that likely, but one has to be careful: linux is not a > research OS]. Point well taken! > > I'm currently working on some ways to increase performance of > low speed/high buffering links, stay tuned. > > -Andi > -- > This is like TV. I don't like TV. I'd like to try out your new code. Anything to improve this dial-up link would be a gift from heaven ;-) 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ .----------------------------------------------------------------------------. | David A. Ranch - Linux/Networking/PC hardware [EMAIL PROTECTED] | !---- ----! `----- For more detailed info, see http://www.ecst.csuchico.edu/~dranch -----' _______________________________________________ Masq maillist - [EMAIL PROTECTED] Admin requests can be handled at http://www.indyramp.com/masq-list/ or email to [EMAIL PROTECTED] PLEASE read the HOWTO and search the archives before posting. You can start your search at http://www.indyramp.com/masq/ Please keep general linux/unix/pc/internet questions off the list.
