`On Sat, Sep 12, 1998 at 05:20:56PM +0200, Andrea Arcangeli wrote:[...]> Yes I just read in 1122 that:> > --- rfc 1122 --->             DISCUSSION:>                  There were two known problems with the RTO calculations>                  specified in RFC-793.  First, the accurate measurement>                  of RTTs is difficult when there are retransmissions.>                  Second, the algorithm to compute the smoothed round->                  trip time is inadequate [TCP:7], because it incorrectly>                  assumed that the variance in RTT values would be small>                  and constant.  These problems were solved by Karn's and>                  Jacobson's algorithm, respectively.> -------> > But where can I find such Karn's and Jacobson's algorithm? I hope not> having to spend money...I suppose you can find the algorithms in the bibliography at the end of the RFC.[...]> I think that it' s really excessive increase the srtt of 4*mdev.  Also I> think that it' s completly broken start with a mdev of 3/4 sec (that then> icrease of at least 3 sec the first retransmit timeout). > > So I think that we should default to 0 mdev at sock creation time and> caculate the rto as the SRTT + MDEV (not 4*MDEV) changing> > 	tp->rto = (tp->srtt >> 3) + tp->mdev;> to> 	tp->rto = (tp->srtt >> 3) + (tp->mdev >> 2);> > I have not done math to prove that this changes would not collapse the> whole Internet (because I am not able to do that ;-), but sound obvious to> me that a first retransmit timeout of ~15 times > of the first rtt is> wrong. > > With my changes if the first rtt is of 143 the first rto become 319 (>2> rtt). This would fit in the RFC793 algorithm and would get the> improvements of the mdev and congestion avoidance calculations.> > I append a simple proggy that done the calc for me (#define STOCK 1 to get> the 2.1.121 calculation and STOCK 0 to get _my_ calc).[...]I don't think that changing the algorithm to use MDEV instead of MDEV*4is a right thing.  I have no figures but I suppose thatSRTT + MDEV keeps the probability of false retransmittions too large.I can agree with you that initialization of tp->mdev by m<<2 when the previousmeasurements are absent is probably an overhead.If we want to keep the initial rto about 3*m as comments say the initialvalue for tp->mdev should be not more than m<<1.In addition you may try to remove the contributionof negative RTT differences to the MDEV evaluation as Rogier Wolffhas suggested.  It'd be interesting to know how the modificationchanges the RTO value and the total TCP performance.Best wishes					Andrey V.					Savochkin-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/faq.html`