-------------------<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.netQ: 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/