Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jan 2004 10:53:54 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        Stuart Pook <Stuart.Pook@infres.enst.fr>
Cc:        andre@freebsd.org
Subject:   Re: send(2) does not block, send(2) man page wrong? 
Message-ID:  <Pine.BSF.4.21.0401261052590.76985-100000@InterJet.elischer.org>
In-Reply-To: <E1Al8xj-0002aR-00@roo>

next in thread | previous in thread | raw e-mail | index | archive | help
do what ping does (ping -f)
when you get an ENOBUFS do a usleep for 1 mSec.
and then send it again.


On Mon, 26 Jan 2004, Stuart Pook wrote:

> > On 23 Jan 2004, Don Lewis wrote:
> > > the send does not give an error: the packet is just thrown away.
> > 
> > Which is the same result as you would get if the bottleneck is just one
> > network hop away instead of at the local NIC.
> 
> But it isn't. I'm broadcasting onto the local network.  With Linux and
> Solaris (which implement what FreeBSD send(2) says), it is so easy: I just
> send(2) away, and because the send blocks when the kernel buffer space is
> full, I lose very few packets.  With FreeBSD, I lose 60% of the packets.
> (The aim is to broadcast onto a private 802.11b network.)
> 
> If I don't want to saturate the network then I will use kernel level
> traffic shaping to limit the outgoing bandwidth.  I have already done this
> on Linux when I was broadcasting onto my 802.11b network via an access
> point connected via 100Mbits/s Ethernet.  I just used traffic shaping
> to limit the outgoing traffic on that Ethernet interface to 3Mbits/s.
> I didn't have to change my program at all.  (At one point I did try
> to put the delays (with nanosleep) into my program but it worked very
> badly because the scheduling delays were too big.  The kernel does it
> so much better.) Once again it is vital that send blocks.
> 
> I guess that I'm out of luck with *BSD.  I hope that someone will update
> the send(2) man page so that the next person who wants to do what I'm
> doing will know that it isn't possible with FreeBSD.
> 
> Stuart
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0401261052590.76985-100000>