Date: Thu, 25 Mar 1999 16:18:12 -0800 (PST) From: Jim Shankland <jas@flyingfox.com> To: billf@chc-chimes.com, j@lumiere.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: 3.1-STABLE dies on 40+ connects Message-ID: <199903260018.QAA21926@biggusdiskus.flyingfox.com> In-Reply-To: <Pine.BSF.4.05.9903251452370.1470-100000@leaf.lumiere.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903260018.QAA21926>