From owner-freebsd-hackers Fri Jul 13 13:14:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 40B7837B401 for ; Fri, 13 Jul 2001 13:14:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.130.157.Dial1.SanJose1.Level3.net [209.245.130.157]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA06896; Fri, 13 Jul 2001 13:14:07 -0700 (PDT) Message-ID: <3B4F56B3.575C5032@mindspring.com> Date: Fri, 13 Jul 2001 13:14:43 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernd Walter Cc: Leo Bicknell , freebsd-hackers@FreeBSD.ORG Subject: Re: Network performance roadmap. References: <20010713101107.B9559@ussenterprise.ufp.org> <3B4F4534.37D8FC3E@mindspring.com> <20010713151257.A27664@ussenterprise.ufp.org> <20010713215956.A20320@cicely20.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Bernd Walter wrote: > > On Fri, Jul 13, 2001 at 03:12:57PM -0400, Leo Bicknell wrote: > > On Fri, Jul 13, 2001 at 12:00:04PM -0700, Terry Lambert wrote: > > > One good way to prevent this is to not unreasonably set > > > your window size... 8-p. > > > > Ah, I see, so to prevent MBUF exhaustion I should not let > > my socket buffers get large. Sort of like to prevent serious > > injury in a car crash I should drive at 10MPH on the freeway. > > > > Performance limits to save a system from crashing should be > > a last resort. > > One point is that if a client gets serviced with more performance > the system can reuses the buffers much sooner. There is a scheduling algorithm for network traffic that attempts to schedule fastest completion first on requests; there is a nice paper on this available from CMU. It turns out that it does not stall the big requests unreasonably, and substantially improves overall throughput. Julian's nifty approach basically controlled the queue size on the sender by being extremely tricky on the receiver, which enabled him to guarantee QOS for various types of data flows, without congesting intermediate hop routers unduly. I let him talk about it if he wants, but I will not say any more without his permission (and with it will probably still defer to him 8-)). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message