Date: Fri, 8 Mar 1996 14:14:11 -0800 From: Matthew Dillon <dillon@backplane.com> To: bugs@FreeBSD.ORG Cc: "Garrett A. Wollman" <wollman@lcs.mit.edu> Subject: srtt calculation bug .. found Message-ID: <199603082214.OAA00252@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
ok, I've found the bug with t_srtt ... the problem is mainly
due to the lack of resolution to SLOWHZ (which is only 500ms).
That coupled with the following:
delta = rtt - 1 - (tp->t_srtt >> TCP_RTT_SHIFT);
if ((tp->t_srtt += delta) <= 0)
tp->t_srtt = 1;
The above equation breaks down statistically for < 500 ms RTT's. You
would think that if the rtt variable is 1 half the time and 2
half the time, that srtt should wind up at around 4 (200 ms).
Unfortunately, that does not occur because this line:
delta = rtt - 1 - (tp->t_srtt >> TCP_RTT_SHIFT);
Fails to generate a negative number in the case where 'rtt' is 1
(i.e. delta time is 0 at a 500ms resolution). However, it DOES
generate a positive number if rtt is 2. The (tp->t_srtt >> TCP_RTT_SHIFT)
also fails to generate a negative number until t_srtt reaches 8, but
by that time it's too late.. you effectively get a random number
depending on when you sample rather then the rtt.
Even if you round tp->t_srtt up by 1/2 (a value of 4), it still breaks
down statistically.
The proper solution is to balance the weighting of an rtt of 1 and an
rtt of 2 (i.e. a delta time of 0 and a delta time of 1).... give the
delta time of 0 a -1 value to match the delta time of 1, as follows:
delta = rtt - 1 - (tp->t_srtt >> TCP_RTT_SHIFT);
if (delta == 0) /* ADD ME */
delta = -1; /* ADD ME */
if ((tp->t_srtt += delta) <= 0)
tp->t_srtt = 1;
Now you have a reasonably balanced weighting and the statistical
calculation no longer breaks down for round trip times < 500ms.
There is one other problem, and that is where you update the route
table rtt when t_rttupdated >= 16. 16 may not be a high enough
number to handle round trip times < 10 ms with a 500 ms timer
resolution.
The solution is to either increase the timer resolution or to increase
rttupdated... though obviously there are practical limits to how
large rttupdated can be and still work.
--
I have tested this on a slip link, and the route table entries come
up with the correct round trip time with the fix in, and the completely
incorrect round trip time without the fix.
-Matt
Matthew Dillon Engineering, BEST Internet Communications, Inc.
<dillon@apollo.backplane.com>
[always include a portion of the original email in any response!]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603082214.OAA00252>