From owner-freebsd-net Thu Mar 25 15: 7:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from biggusdiskus.flyingfox.com (parker-T1-2-gw.sf3d.best.net [209.157.165.30]) by hub.freebsd.org (Postfix) with ESMTP id 61FCB150AA for ; Thu, 25 Mar 1999 15:07:08 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.8/8.8.5) id QAA21926; Thu, 25 Mar 1999 16:18:12 -0800 (PST) Date: Thu, 25 Mar 1999 16:18:12 -0800 (PST) From: Jim Shankland Message-Id: <199903260018.QAA21926@biggusdiskus.flyingfox.com> To: billf@chc-chimes.com, j@lumiere.net Subject: Re: 3.1-STABLE dies on 40+ connects Cc: freebsd-net@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > All of these are _really_ backed up. > > Well, this is over an ethernet connection. 40 clients, each doing 128kbps > clogs it pretty bad. =) But it confirms Matt Dillon's theory that the > buffers have been made larger than 16k. It's not the Ethernet that's backed up. The bytes stay in the send buffers until they're acked by the receiving end. It's trivial for a program to fill the send buffer to its limit; you just have to be able to do write() calls faster than data can be delivered and ACKed by the remote end. > > > tcp 0 16015 207.218.152.15.8000 206.170.14.10.2268 > > > ESTABLISHED > > > > These seem to be handling the data in a timely fashion. > > Same overloaded ethernet link. But they're all <= 16k. The first program has explicitly increased the size of its send buffers with setsockopt(). The second has not, and gets the default size. In both cases, the send buffers are (near) full. The real problem is that the write() calls should be stalling or returning ENOBUFS (preferably the former) when no more mbuf clusters are available. Jim Shankland NLynx Systems, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message