Rx: Treat rx_minPeerTimeout not as a minimum but as padding

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>

diff --git a/src/rx/rx.c b/src/rx/rx.c
index f09d519ba5302049a81f3046822b759b330c1d7e..d545e7c09434f00638be5df157aea441144ce842 100644 (file)
--- a/src/rx/rx.c
+++ b/src/rx/rx.c
@@ -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);