[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-net
Subject:    very old rtt calculation bug?
From:       Thor Lancelot Simon <tls () coyotepoint ! com>
Date:       2010-07-27 3:30:01
Message-ID: 20100727033000.GA11079 () panix ! com
[Download RAW message or body]

A coworker is looking at some ad-hoc stack tuning for heavy load which
has parameters that depend on rtt.  We are seeing the smoothed rtt vary
for TCP connections on loopback in ways we don't expect.

We have begun to suspect that the changes in tcp_input.c 1.16 and 1.27
are wrong.  In particular, as my coworker points out:

| I am pretty sure the NetBSD algo is wrong:
| 
|         if (tp->t_srtt != 0) {
|                 /*
|                  * srtt is stored as fixed point with 3 bits after the
|                  * binary point (i.e., scaled by 8).  The following magic
|                  * is equivalent to the smoothing algorithm in rfc793 with
|                  * an alpha of .875 (srtt = rtt/8 + srtt*7/8 in fixed
|                  * point).  Adjust rtt to origin 0.
|                  */
|                 delta = (rtt << 2) - (tp->t_srtt >> TCP_RTT_SHIFT);
|                 if ((tp->t_srtt += delta) <= 0)
|                         tp->t_srtt = 1 << 2;
| 
| The (rtt << 2) means that we are adding 1/2 the RTT to srtt, rather than 1/8.
| Given that srtt is << 3, if we do not shift rtt by anything, adding it to
| srtt adds rtt/8 to it.

FreeBSD shifts rtt by two here, but they keep 5 bits of precision vs our 3,
so there it's correct.

Are we missing something?

Thor
[prev in list] [next in list] [prev in thread] [next in thread]