On 2007-Jul-31 22:11:56 +0000, Peter Wemm <[EMAIL PROTECTED]> wrote: > To demonstrate, boot with kern.hz=100. ssh to a box on local ethernet > and establish a reliable round-trip-time (ie: type a few commands). > Then unplug the ethernet and press a key. Time how long it takes to > drop the connection.
I've bumped into this problem as well but chose a slightly different solution. I've left the TCPTV_MIN/tcp_rexmit_min code alone (because I believed the bit about it being scaled to hz). Instead I added a new sysctl "Minimum Retransmission Period before Dropping Connection" and require that a connection's t_rxtshift remain at TCP_MAXRXTSHIFT until that time has expired. My gut feeling is that putting an artifical lower bound on the RTT is a hackish way to control the retransmit timeout - I thought the TCP algorithms relied on knowing the real RTT to correctly handle retransmissions. A variable that explicitly controls the retransmit timeout would seem easier to understand. I thought I'd PR'd the patch but it looks like I haven't. If anyone is interested, I'll submit it. -- Peter Jeremy
pgpu5H24vftNN.pgp
Description: PGP signature
