On Monday 10 February 2003 16:57, John Heffner wrote: > On Mon, 10 Feb 2003, Martin Zielinski wrote: > > On Monday 10 February 2003 13:38, David S. Miller wrote: > > > From: Martin Zielinski <mz@seh.de> > > > Date: Mon, 10 Feb 2003 13:54:28 +0100 > > > > > > Remember the situation: > > > - Linux wants to transmit data sending a packet with window size > > > e.g. 5840 - The receiver can't use the data (printer paper empty) -> > > > ACK window size 0 - Linux takes a timeout (tp->probes_out is zero after > > > receiving the ACK) ... LOOP - The Timeout between these cycles is > > > doubled by the use of tp->backoff (tp->rto << tp->backoff) until > > > TCP_MAX_RTO is reached. > > > > > > Ok, then just limit tp->backoff in tcp_send_probe0() like this: > > > > > > if (tp->backoff < sysctl_tcp_retry2) > > > tp->backoff++; > > > > > > I think this fixes the bug more elegantly. > > > > Whatever you mean. I just wanted this behaviour out - although it seems, > > that nobody ever had problems with stalled connections... > > This is probably because you were running on a StrongARM. I believe on an > i386 this bug will not show up so badly because rto << backoff is > effectively rto << (backoff % 32). The backoff will effectively just > cycle through again every 45 mins. On the ARM (though I have never used > one), it seems the shift of >31 always results in zero. I believe this > bug should also show up on alpha and ia64. > > -John John is absolutly right. Never tried this on i386 'cause my arm systems loads a kernel and boots up in 20 seconds... Thanks. The world is still a globe ...again :-) -- Martin Zielinski mz@seh.de - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
