> 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.
> 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.
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?
> 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
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
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].
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.- 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/