From owner-freebsd-questions Tue Nov 28 10:36:33 2000 Delivered-To: freebsd-questions@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 87B7537B400 for ; Tue, 28 Nov 2000 10:36:30 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eASIaUw16343; Tue, 28 Nov 2000 10:36:30 -0800 (PST) Date: Tue, 28 Nov 2000 10:36:29 -0800 From: Alfred Perlstein To: Lars Eggert Cc: questions@FreeBSD.ORG Subject: Re: send(2) and resuming after ENOBUFS Message-ID: <20001128103629.K8051@fw.wintelcom.net> References: <3A2326E6.AD835284@isi.edu> <20001127220700.W8051@fw.wintelcom.net> <3A23EE64.D50FD149@isi.edu> <20001128094820.I8051@fw.wintelcom.net> <3A23F7C2.EC30C6E9@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A23F7C2.EC30C6E9@isi.edu>; from larse@ISI.EDU on Tue, Nov 28, 2000 at 10:21:54AM -0800 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Lars Eggert [001128 10:21] wrote: > Alfred Perlstein wrote: > > > > * Lars Eggert [001128 09:41] wrote: > > > Alfred Perlstein wrote: > > > > > > I am running this with maxusers=128, and as far as I can tell, mbufs are > > > not the problem: > > > > > > [root@hbo: /nfs/ruby/larse/projects/thesis/bin] netstat -m > > > 139/2192/10240 mbufs in use (current/peak/max): > > > 132 mbufs allocated to data > > > 7 mbufs allocated to packet headers > > > 128/1166/2560 mbuf clusters in use (current/peak/max) > > > 2880 Kbytes allocated to network (37% of mb_map in use) > > > 0 requests for memory denied > > > 0 requests for memory delayed > > > 0 calls to protocol drain routines > > > > > > Looking at the send(2) man page, I agree that ENOBUFS doesn't mean that the > > > send buffer is full: > > > > > > [ENOBUFS] The system was unable to allocate an internal buffer. > > > The operation may succeed when buffers become avail- > > > able. > > > > > > [ENOBUFS] The output queue for a network interface was full. > > > This generally indicates that the interface has > > > stopped sending, but may be caused by transient con- > > > gestion. > > > > > > However, since a too low maxusers is not the problem, I'm still looking for > > > a way of detecting when to resume sending after ENOBUFS, without > > > spinning... > > > > You'll have to spin, or at least call nanosleep or something to back > > off for a bit. Are you getting full network utilization even when > > getting ENOBUFS? Like ~11MB/sec on 100mbit full duplex? Or are > > you falling short of full throughput? What network card are you > > using? > > Some sender host/card info: > > CPU: Pentium III/Pentium III Xeon/Celeron (731.47-MHz 686-class CPU) > xl0: <3Com 3c905C-TX Fast Etherlink XL> > > I'm seeing about 96Mb/s on a 100Mb/s full-duplex link, so I'm at link > capacity. > > The problem with using nanosleep() is that I have no idea how long to sleep > for in the general case. (Sure, I can pick good value based on the link > speed/message size, but not if those vary.) Well the idea is to yeild for a small time and just try again. Another option would be to keep track of how much data is actually being sent per-interval and do some sliding based on time. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message