Messages in this thread | | | Date | Tue, 03 Aug 1999 20:30:24 -0500 | From | paulr <> | Subject | Re: Vegas_cong_avoid patch redux (was Re: TCP Vegas Patch) LONG |
| |
Andi Kleen wrote: > > reichp@ameritech.net (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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |