Thor Lancelot Simon <tls%coyotepoint.com@localhost> writes:
> 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?
Bev Schwartz, Laura Ma, and I have been looking at this. This is from
memory -- defuzzed version and patch to follow probably next week.
There are several problems in the RTT code.
value is stored with a +1 to let 0 be special, but it's not subtracted
before use
rounding errors when dealing with very low RTTs
"very low" is not that low because this is based on a long timer tick
We have a fix for the first two problems; with the fix TCP performs
better under loss due to faster RTO processing.
Attachment:
pgpU4sAkxz88w.pgp
Description: PGP signature