On Monday 10 February 2003 13:12, you wrote: > From: Martin Zielinski <mz@seh.de> > Date: Mon, 10 Feb 2003 12:48:39 +0100 > > I think, you overlooked the reseting of tp->probes_out in > tcp_input.c - tcp_ack() to 0 with each ACK coming back from the > receiver. tp->packets_out must be 0 - otherwise the relevant code in > tcp_send_probe0 would not be reached so the code jumps to the "no_queue" > label. > > And by mentioning this you unearth the real bug, tp->backoff needs > to be reset here where tp->probes_out is reset. No, that's not the solution. 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. This is absolute correct behaviour. When (tp->rto << tp->backoff) is greater than TCP_MAX_RTO, the tp->backoff value is not relevant anymore. Nevertheless the timeout should be doubled until than. Resetting tp->backoff would cause the timeout to stay at its initial value. This would cause lots of traffic. The bug is simply, that (tp->rto << tp->backoff) becomes zero after 31 or 32 cycles (on a 32 bit machine) and the timeout becomes zero, too. This can be avoided by adding a line in tcp_send_probe0: + if (min(tp->rto << (tp->backoff+1), TCP_RTO_MAX) != TCP_RTO_MAX) tp->backoff++; Perhaps someone finds a nicer solution, but this one works. Bye, Martin > Can you make this change and see if this makes your problem > go away? > > Alexey, anything missed here? Maybe only reset tp->backoff when > tp->probes_out is non-zero at this point? -- 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
