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 - : 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
