Date: Mon, 26 Jan 2004 16:47:43 +0100 From: Stuart Pook <Stuart.Pook@infres.enst.fr> To: Don Lewis <truckman@freebsd.org> Cc: andre@freebsd.org Subject: Re: send(2) does not block, send(2) man page wrong? Message-ID: <E1Al8xj-0002aR-00@roo> In-Reply-To: Message from truckman@FreeBSD.org of Fri, 23 Jan 2004 18:02:37 -0800. <200401240202.i0O22b7E068823@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1Al8xj-0002aR-00>