[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

**To**:**tech-net%netbsd.org@localhost****Subject**:**very old rtt calculation bug?****From**:**Thor Lancelot Simon <tls%coyotepoint.com@localhost>**- Date: Mon, 26 Jul 2010 23:30:01 -0400

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

**Follow-Ups**:**Re: very old rtt calculation bug?***From:*Greg Troxel

- Prev by Date:
**Fast Forwarding** - Next by Date:
**re: ikphy negotiation problem with cisco** - Previous by Thread:
**Fast Forwarding** - Next by Thread:
**Re: very old rtt calculation bug?** - Indexes: