I havent been really paying attention to this thread, but
   maybe increasing the value of kern.mbuf.nmbclusters with sysctl -w might
   fix the problem.  Or you might want to recompile your kernel with a higher
   value for NMBCLUSTERS.

   On Sun, Jun 24, 2001 at 01:15:58PM -0400, Kevin P. Neal wrote:
   > On Sat, Jun 23, 2001 at 08:30:59PM -0400, Brad Spencer wrote:
   > > One potential reason for this is an overloaded ppp link.  This plagued me
   > > when a 28.8 async. ppp link was my only connection to the Net.
   > > 
   > > What I think occurs is that there is so much backed up traffic waiting to
   > > go out the pipe that the system runs out of space.  This effects UDP and
   > > ICMP traffic the most.
   > 
   > Which is totally unacceptable. 
   > 
   > It seems unreasonable for the link to become so backed up that nothing
   > can ever be sent out of it again (until it is bounced). 
   > 
   > Why can't it drop data with 'no buffer space' errors while it tries to
   > send what it does currently have in buffers?
   > -- 
   > "A method for inducing cats to exercise consists of directing a beam of
   > invisible light produced by a hand-held laser apparatus onto the floor ...
   > in the vicinity of the cat, then moving the laser ... in an irregular way
   > fascinating to cats,..." -- US patent 5443036, "Method of exercising a cat"



With the problem of a link being over loaded, that will help some, but it
will probably not make all instances go away.  A reasonably fast computer
can still fill any amount of space that is provided, if the link is backed
up enough.

I think I was up to 32k when all I had to the Net was a 28.8 link [which
was usually a bit less, as we had rather bad phone lines where I am at].
I would still get "no buffer space" messages from time to time.





Brad Spencer - brad@anduin.eldar.org
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]
[finger brad@anduin.eldar.org for PGP public key]