Messages in this thread | | | Date | Sun, 14 Nov 1999 23:02:17 +0100 | From | Jamie Lokier <> | Subject | Re: Skyhigh retransmit times. Yearold problem still in 2.3.26 |
| |
Andi Kleen wrote: > > Not if TCP does not retry for the duration of your "connected" window, > > say 5 minutes... > > It does. The retransmit timeout is clamped at 120s, when there is anything > to send, and no timeout when there is nothing to send (except for keepalives, > but these are only turned on by some applications) > > > Also, I'm not convinced TCP resets the timeouts when they are so large > > so much as takes them back down slowly. This is useless if your > > connection disappeared for a few minutes and then TCP takes longer than > > you have left to recover. > > It does. The rtt estimate TCP keeps is independent from the retransmit > timeout (tp->rto vs tp->srtt). The rtt estimate only changes based on > new incoming acks, and only for ACKs where TCP knows that the packets > causing them have not been retransmitted.
Hi Andi. Please can you explain the behaviour I get? I have a modem which will connect for about 2 minutes at a time. Reconnecting takes about 2 minutes also -- the callback PPP negotiation sequence is not fast.
I connect and establish an ssh connection (which uses keepalives). All goes well until the modem loses the connection. It always does this just when I've typed something and the response hasn't come back. The modem is back 2 minutes later. Of course, there is no hope of the session continuing -- the retransmits are too far apart.
If they are clamped at 120s, should I expect to be able to continue a session about half the time? I find about 1 in 30 sessions will continue.
Thanks, -- Jamie
- 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/
| |