Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Nov 2000 10:36:29 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Lars Eggert <larse@ISI.EDU>
Cc:        questions@FreeBSD.ORG
Subject:   Re: send(2) and resuming after ENOBUFS
Message-ID:  <20001128103629.K8051@fw.wintelcom.net>
In-Reply-To: <3A23F7C2.EC30C6E9@isi.edu>; from larse@ISI.EDU on Tue, Nov 28, 2000 at 10:21:54AM -0800
References:  <3A2326E6.AD835284@isi.edu> <20001127220700.W8051@fw.wintelcom.net> <3A23EE64.D50FD149@isi.edu> <20001128094820.I8051@fw.wintelcom.net> <3A23F7C2.EC30C6E9@isi.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
* Lars Eggert <larse@ISI.EDU> [001128 10:21] wrote:
> Alfred Perlstein wrote:
> > 
> > * Lars Eggert <larse@ISI.EDU> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001128103629.K8051>