Rx: Treat rx_minPeerTimeout not as a minimum but as padding
authorJeffrey Altman <jaltman@your-file-system.com>
Thu, 21 Oct 2010 18:13:03 +0000 (14:13 -0400)
committerJeffrey Altman <jaltman@openafs.org>
Sat, 23 Oct 2010 19:44:15 +0000 (12:44 -0700)
An improved RTT and timeout calculation algorithm is being
developed but until we have it, treat rx_minPeerTimeout not as
a minimum value for the timeout but as padding to be added to
the measured RTT when computing the peer timeout value.

With this change rx does not begin to send large numbers of
resends when the RTT begins to exceed the rx_minPeerTimeout
value.  Timeout triggered resends at the moment can force rx
into fast recovery mode which in turn kills performance.  It
is better to avoid that problem for now.

Change-Id: Iff5e81d7cf1366e1810f118bf4825274696769c9
Reviewed-on: http://gerrit.openafs.org/3026
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>

src/rx/rx.c

index f09d519..d545e7c 100644 (file)
@@ -6633,11 +6633,11 @@ rxi_ComputeRoundTripTime(struct rx_packet *p,
        peer->rtt = _8THMSEC(rttp) + 8;
        peer->rtt_dev = peer->rtt >> 2; /* rtt/2: they're scaled differently */
     }
-    /* the timeout is RTT + 4*MDEV but no less than rx_minPeerTimeout msec.
+    /* the timeout is RTT + 4*MDEV + rx_minPeerTimeout msec.
      * This is because one end or the other of these connections is usually
      * in a user process, and can be switched and/or swapped out.  So on fast,
      * reliable networks, the timeout would otherwise be too short. */
-    rtt_timeout = MAX(((peer->rtt >> 3) + peer->rtt_dev), rx_minPeerTimeout);
+    rtt_timeout = ((peer->rtt >> 3) + peer->rtt_dev) + rx_minPeerTimeout;
     clock_Zero(&(peer->timeout));
     clock_Addmsec(&(peer->timeout), rtt_timeout);