Date: Fri, 13 Jul 2001 11:47:19 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Leo Bicknell <bicknell@ufp.org>, Drew Eckhardt <drew@PoohSticks.ORG>, hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <200107131847.f6DIlJv67457@earth.backplane.com> References: <200107130128.f6D1SFE59148@earth.backplane.com> <200107130217.f6D2HET67695@revolt.poohsticks.org> <20010712223042.A77503@ussenterprise.ufp.org> <200107131708.f6DH8ve65071@earth.backplane.com> <20010713132903.A21847@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:On Fri, Jul 13, 2001 at 10:08:57AM -0700, Matt Dillon wrote:
:> The basic problem with calculating the bandwidth delay product is that
:> it is an inherently unstable calculation. It has to be a continuous,
:
:I think you're doing good work, but I'm concerned you're going down
:a road that's going to take a very long time to get right. It is not
:necessary to calculate the bandwidth*delay in order to prevent over-
:buffering. Preventing overbuffering only requires tracking the maximum
:bandwidth*delay value, assuming that we always want the ability to
:buffer that much data. I think the number of cases where it decreases
:significantly over the peak for a long enough time to make a difference
:is minimal.
:
:Fully knowing the value over time could lead to optimizations like
:shrinking the buffers, or attempting to prevent some packet loss by
:not over-increasing the window. However oscellation and other issues
:I think are going to make this very complex.
:
:--
:Leo Bicknell - bicknell@ufp.org
:Systems Engineer - Internetworking Engineer - CCIE 3440
Well, you'd be surprised. 90% of the world still uses modems, so
from the point of view of a web server it would be a big win. The
bigger picture is more complex... certainly the instability of the
algorithm is a big issue, but it opens the door to research because
congestion avoidance and bandwidth and latency guarentees across an
arbitrary network ultimately come down to having to deal with something
like this.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107131847.f6DIlJv67457>