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/