Date: Wed, 8 Feb 2006 22:42:40 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: "Ricardo A. Reis" <ricardo_bsd@yahoo.com.br> Cc: net@freebsd.org Subject: Re: RELENG_6 No buffer space available [udp stream] Message-ID: <20060208223956.X57882@fledge.watson.org> In-Reply-To: <43EA25EF.3020105@yahoo.com.br> References: <43EA25EF.3020105@yahoo.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Feb 2006, Ricardo A. Reis wrote: > I have a problem with iperf and single udp stream, > > [freebsd - RELENG_6] - >>> [ linux-2.6.X] > > I in use server mode and no problem occurred, but in client mode this no > complete a udp stream > > iperf -c 172.22.1.142 -u -b 100M -t 30 > ------------------------------------------------------------ > Client connecting to 172.22.1.142, UDP port 5001 > Sending 1470 byte datagrams > UDP buffer size: 41.1 KByte (default) > ------------------------------------------------------------ > [ 3] local 172.22.1.166 port 51517 connected with 172.22.1.142 port 5001 > write2 failed: No buffer space available ENOBUFS is the error returned when a process is sending packets faster than the transmitting interface can actually transmit them. It occurs when the interface send queue fills, and the packet is dropped. As UDP is a lossy datagram protocol without flow control, your process doesn't block, but it does get back an error telling it that the packet could not be transmitted. I'm not sure how Linux behaves under the same conditions -- it could be there is silent drop (send returns 0, but the packet is dropped). If the application has been written without knowing that send() can fail for UDP, it might not know how to take that into account, and might exit/error out improperly. Robert N M Watson > [ 3] 0.0- 0.1 sec 1.45 MBytes 100 Mbits/sec > [ 3] Sent 1037 datagrams > [ 3] Server Report: > > > # netstat -mb > 1/839/840 mbufs in use (current/cache/total) > 0/438/438/16832 mbuf clusters in use (current/cache/total/max) > 0/4/4464 sfbufs in use (current/peak/max) > 0K/1085K/1086K bytes allocated to network (current/cache/total) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 11 calls to protocol drain routines > > > Thanks > > Ricardo A. Reis > UNIFESP > Unix and Network Admin > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060208223956.X57882>