From owner-freebsd-net Fri Mar 26 0: 8:21 1999 Delivered-To: freebsd-net@freebsd.org Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (Postfix) with SMTP id 016A815568 for ; Fri, 26 Mar 1999 00:07:30 -0800 (PST) (envelope-from pete@sms.fi) Received: from sms.fi (localhost.sms.fi [127.0.0.1]) by silver.sms.fi (8.9.2/8.9.2) with ESMTP id KAA20841; Fri, 26 Mar 1999 10:07:06 +0200 (EET) (envelope-from pete@sms.fi) Message-ID: <36FB402A.5785497D@sms.fi> Date: Fri, 26 Mar 1999 10:07:06 +0200 From: Petri Helenius X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: en,fi MIME-Version: 1.0 To: Jim Shankland Cc: j@lumiere.net, freebsd-net@FreeBSD.ORG Subject: Re: mbuf clusters and socket send buffers (was Re: 3.1-STABLE dies on 40+ connects) References: <199903260054.QAA22060@biggusdiskus.flyingfox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim Shankland wrote: > > A thought related to this discussion: does it make sense to allow the > send buffers to be larger than the peer's advertised window size? > In other words, why "preposition" those bytes in the kernel before > the peer has indicated a willingness to accept them? > If you have high bandwidth paths which low latency, the kernel can send the window faster than your process gets scheduled again. So it's useful to have multiple windows worth of send buffers. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message