From owner-freebsd-hackers Fri Jul 13 11:26:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id DFA5837B403 for ; Fri, 13 Jul 2001 11:26:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA70023; Fri, 13 Jul 2001 13:14:08 -0700 (PDT) Date: Fri, 13 Jul 2001 13:14:07 -0700 (PDT) From: Julian Elischer To: Leo Bicknell Cc: freebsd-hackers@freebsd.org Subject: Re: Network performance roadmap. In-Reply-To: <20010713101107.B9559@ussenterprise.ufp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 13 Jul 2001, Leo Bicknell wrote: > [...] I think you have analysed it very well.. I can summarise: We want the ability to make the current window to be able to grow to a very large value if the link needs it. So sndbuf shold eb set high. We don't want every process buffering in advance the entire potential maximum window size of data, but rather some safety margin over what is likely to be needed in a hurry by the tcpstack with it's instantaneous window. We don't want to make processes stop and start too much buffering small ammounts of data. I would suggest that 2 * the current window may be too small because the window might be increasing and reception of one ack might move the window up by the entire transmitted window size, resulting in starvation if the waiting data can be sent quickly. therefore I suggest a few modifying factors: A minimum value of something like 16K use 3* cWIN rather than 2* as a lower bound. also try figure out how much data we can send in 0.1 sec and use that as part of the calculation. Some systems with LOTS of server threads don't want to keep scheduling them but would rather have a minimum amount of data queued to allow fairly 'chunkuy' scheduling. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message