tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: very old rtt calculation bug?
hi,
> 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.
what's the status of this?
YAMAMOTO Takashi
Home |
Main Index |
Thread Index |
Old Index