*BSD News Article 15823


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!swrinde!cs.utexas.edu!uwm.edu!ogicse!usenet.ee.pdx.edu!pdxgate!parsely!agora!implode!davidg
From: davidg@implode.rain.com (David Greenman)
Newsgroups: comp.os.386bsd.bugs
Subject: Re: Ping problem
Message-ID: <C6rIt5.1wp@implode.rain.com>
Date: 9 May 93 13:58:16 GMT
Article-I.D.: implode.C6rIt5.1wp
Organization: Delta Systems, Portland, OR.
Lines: 37

wittlin@sci.kun.nl (Aleksander Wittlin) writes:
>I get a strange message from ping ( 486 8Mb, 0.1+patchkit 0.2.2 + we0 ):
>ping machine.xx.xx
>ping: wrote machine.xx.xx 64 chars, ret -1
>ping: sendto: No buffer space available

   Since several people have asked me questions about this problem in
email, it seems appropriate that I should post a response to the net.
   In my last response about this, I made an assumption that the problem
is related to SLIP, even though nothing was said about it in the original
posting...well...
   I just looked through the code that I released, and it appears that I'm
mistaken - the release to the world of the SLIP driver *does* have the check
for queue depth. It does, however, return ENOBUFS when the queue max is
reached. What this means is that whenever the traffic on the SLIP net gets
real high (as in *many* active connections), this problem will show itself.
The solution should be the same, though - increase the ifq_maxlen parameter
from the default of 50 to something somewhat higher. This assumes that the
problems you are having are transient. If instead they last for an extended
period, this would suggest that the packets are backing-up in the queue for
other reasons (like CTS being off for long periods of time in the case of
SLIP). I wouldn't recommend changing this system wide - rather I would try
testing a change with individual devices. The variable if_snd.ifq_maxlen
(in the ifnet structure, I believe) is what gets checked, and it is usually
initialized in /sys/net/if.c. SLIP is an exception to this, though - it
inits this variable itself (hardcoded to 50). Another thing you could try
would be to increase the SLIP MTU. Note that because the MCLBYTES param
is normally 1024 bytes, that the MTU will never exceed this (in fact the
kernel will panic if the SLIP MTU is set to more than about 950). It is
likely that the interim release of 386BSD (0.1.5) will have this changed
to 2048. With it at 1024, even ethernet traffic is forced to use small
packets - in some cases fragmenting them to 1024 and 500 (approx).
   What I've said above might not have anything to do with your specific
problem.
:-) So take it as advisory.

-DG