Date: Fri, 27 Dec 1996 16:25:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: proff@suburbia.net Cc: mango@staff.communique.net, hackers@FreeBSD.ORG Subject: Re: Help 'no buffer available'!! Message-ID: <199612272325.QAA25506@phaeton.artisoft.com> In-Reply-To: <19961226064814.5747.qmail@suburbia.net> from "proff@suburbia.net" at Dec 26, 96 05:48:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > My poor news server is sick..... > > > > ----kiyoko:/var/log# ping akira > > PING akira.communique.net (204.27.65.10): 56 data bytes > > 64 bytes from 204.27.65.10: icmp_seq=0 ttl=255 time=0.867 ms > > ping: sendto: No buffer space available > > ping: wrote akira.communique.net 64 chars, ret=-1 > > ping: sendto: No buffer space available > > I often get this as well. What is the philosophy in having > sendto() et al return an error, rather than block until > buffer space is available? It is my opinion that an error return of this type is *absolutely necessary* to allow applications to correctly back off in "source quench" conditions. Don't misunderstand me... I think failure to meet bandwidth commitments is an evil, evil thing, and "leaky bucket" implementations of ATM and other non-committed rate transports should be banned and thier proponents hung. The general idea is that the provider sells to more customers than he has bandwidth to support, and everyone gets screwed equally as the bandwidth is overused. However. Source quench is something we have to live with, and it is arguable that your sending application is buggy if it is not handling the condition gracefully (see Stevens for a better discussion of sendto errors and their causes...). For your particular case, look for an mbuf leak on an error condition, since I believe taking the interface down and bringing it back up is known to clear the problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612272325.QAA25506>