FreeBSD problems and preliminary ways to solve

[Slawa Olhovchenkov]

On Fri, Aug 19, 2011 at 10:36:29AM +0100, Robert N. M. Watson wrote:

> 
> On 19 Aug 2011, at 10:05, Slawa Olhovchenkov wrote:
> 
> >> Is the issue here that FreeBSD is dropping more packes, or just that FreeBSD 
> >> is reporting that it drops packets?  Historically, we've returned ENOBUFS from 
> >> datagram sockets when the interface queue is overflowed, but some other 
> >> systems (most noticeably Linux) simply return success when they drop a packet 
> >> on an outgoing interface queue.  You can debate which is the better model, but 
> >> one impact is that sometimes people report errors on FreeBSD that they don't 
> >> see on Linux -- when actually, the same failure is present, we just allow the 
> >> application to learn about it.
> > 
> > Historically, Linux on datagram (UDP) socket allow use select, FreeBSD
> > -- don't allow. FreeBSD always report 'UDP socket ready to transmit'.
> > And after try to send packet -- 'oops, ENOBUFS'.
> 
> 
> And if you have two consumers sending UDP on Linux, they both get unreported 50% packet loss, to my understanding?

In my test I use netperf.
netperf/UDP on linux send only packets can be proccessed by box (and
NIC) and packets don't drop. netperf don't allocate all CPU cycles.

netperf/UDP on FreeBSD get all CPU, try to send HUGE UDP flow and
report about massive packets drop. select on UDP socket report 'ready' allways.