From owner-freebsd-hackers Fri Jul 13 10:29: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id C89FD37B401 for ; Fri, 13 Jul 2001 10:29:06 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f6DHT3Z22404; Fri, 13 Jul 2001 13:29:03 -0400 (EDT) (envelope-from bicknell) Date: Fri, 13 Jul 2001 13:29:03 -0400 From: Leo Bicknell To: Matt Dillon Cc: Leo Bicknell , Drew Eckhardt , hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <20010713132903.A21847@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , Matt Dillon , Leo Bicknell , Drew Eckhardt , hackers@FreeBSD.ORG References: <200107130128.f6D1SFE59148@earth.backplane.com> <200107130217.f6D2HET67695@revolt.poohsticks.org> <20010712223042.A77503@ussenterprise.ufp.org> <200107131708.f6DH8ve65071@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107131708.f6DH8ve65071@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Jul 13, 2001 at 10:08:57AM -0700 Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message