From owner-freebsd-hackers Fri Jul 13 10: 9: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7CE1A37B401 for ; Fri, 13 Jul 2001 10:09:07 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f6DH8ve65071; Fri, 13 Jul 2001 10:08:57 -0700 (PDT) (envelope-from dillon) Date: Fri, 13 Jul 2001 10:08:57 -0700 (PDT) From: Matt Dillon Message-Id: <200107131708.f6DH8ve65071@earth.backplane.com> To: Leo Bicknell Cc: Drew Eckhardt , Leo Bicknell , hackers@FreeBSD.ORG Subject: Re: Network performance tuning. References: <200107130128.f6D1SFE59148@earth.backplane.com> <200107130217.f6D2HET67695@revolt.poohsticks.org> <20010712223042.A77503@ussenterprise.ufp.org> 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 Ok, I'm about half way through writing up a patch set to implement the bandwidth delay product write-buffer calculation. It may still be a few days before it is presentable. The TCP stack already has almost everything required to do the calculation. Adding a fair-share piece in addition to the bwdelay product will also be fairly easy, at least for the write-side. The basic problem with calculating the bandwidth delay product is that it is an inherently unstable calculation. It has to be a continuous, slow moving calculation or you have a good chance of destabilizing the network (think about having a thousand connections all trying to figure out each of their bandwidth delay productions for traffic sharing random hops in the network). The advantage of being able to do it successfully, however, is huge. Rather then allowing the TCP connection to start to lose packets before backing off, the bandwidth delay product calculation instead focuses on not overloading the network in the first place while still maintaining optimum performance. I took a look at the paper Leo pointed out to me: http://www.psc.edu/networking/auto.html It's a very interesting paper, and the graphs do in fact show the type of instability that can occur. The code is a mess, though. I think it is possible to generate a much less noisy patch set by taking a higher level approach to solving the problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message