From owner-freebsd-arch@FreeBSD.ORG  Fri Aug 19 09:50:33 2011
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 20A5C1065670;
	Fri, 19 Aug 2011 09:50:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98])
	by mx1.freebsd.org (Postfix) with ESMTP id 76E218FC19;
	Fri, 19 Aug 2011 09:50:32 +0000 (UTC)
Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD))
	(envelope-from <slw@zxy.spb.ru>)
	id 1QuLit-000PTZ-EC; Fri, 19 Aug 2011 13:50:43 +0400
Date: Fri, 19 Aug 2011 13:50:43 +0400
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: "Robert N. M. Watson" <rwatson@FreeBSD.org>
Message-ID: <20110819095043.GB2362@zxy.spb.ru>
References: <slrnj4oiiq.21rg.vadim_nuclight@kernblitz.nuclight.avtf.net>
	<810527321.20110819123700@serebryakov.spb.ru>
	<alpine.BSF.2.00.1108190939340.93669@fledge.watson.org>
	<319607032.20110819125005@serebryakov.spb.ru>
	<alpine.BSF.2.00.1108190954420.93669@fledge.watson.org>
	<20110819090536.GA92576@zxy.spb.ru>
	<FBF0BBA4-7694-438C-93CF-84E25ABAFF73@FreeBSD.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FBF0BBA4-7694-438C-93CF-84E25ABAFF73@FreeBSD.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: slw@zxy.spb.ru
X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false
Cc: Lev Serebryakov <lev@FreeBSD.org>, freebsd-arch@freebsd.org
Subject: Re: FreeBSD problems and preliminary ways to solve
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2011 09:50:33 -0000

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.