From owner-svn-src-all@FreeBSD.ORG Fri Oct 5 19:04:10 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5652C106566C; Fri, 5 Oct 2012 19:04:10 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AD2F08FC08; Fri, 5 Oct 2012 19:04:09 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so1559047wey.13 for ; Fri, 05 Oct 2012 12:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=p4Pm+Uv5Bh/dkfIszne4J8cL6jIrtYFqllx9Ca9HWIQ=; b=Gb0U7hJAeGyPalesLpnxrt+XpvwlFYNwfkxnRpUl3kOjOOvu+D6X6NefflgNWMiVCU +RYb+DzmrKDrbDs42RZcncYNTP7uI5wEvRObA20OtAlIzKq25PfbgNLy3Ac/yF9EITMC A1bh/r3qr3YhK9Gl+I+CaDasDoC8+0FOZnPoRW/IErGCGl2Yyewxr2R7i/HKVZKdrhw6 LYWX82yZATqIGx5tK/++WGoSMIURh9NK/1aUB6uCyVT/j6b+8gXuj3lmFIRT7Fk5E/Qx xWv472bkvZq7MQ81/LVnTJIkA7/Ixu+ii6TYOLHYORYDe5Uqckce+lLmBCKf04bXOHgF gITA== Received: by 10.180.108.45 with SMTP id hh13mr5128939wib.15.1349463848363; Fri, 05 Oct 2012 12:04:08 -0700 (PDT) Received: from [10.0.0.86] ([93.152.184.10]) by mx.google.com with ESMTPS id fb20sm4314994wid.1.2012.10.05.12.04.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 12:04:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=koi8-r From: Nikolay Denev In-Reply-To: <20121005175024.GV34622@glebius.int.ru> Date: Fri, 5 Oct 2012 22:04:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <52437C79-E04A-4C93-9E83-EF07D17D34F2@gmail.com> References: <201209201005.q8KA5BqZ094414@svn.freebsd.org> <2966A49C-DE3F-4559-A799-D1E9C0A74A9C@gmail.com> <20121005070914.GI34622@glebius.int.ru> <20121005080453.GL34622@glebius.int.ru> <2109548116005159772@unknownmsgid> <20121005151139.GS34622@glebius.int.ru> <67EC4A5E-752C-4476-9C95-8BAA3A8F49BC@gmail.com> <20121005175024.GV34622@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1498) Cc: "svn-src-all@freebsd.org" Subject: Re: svn commit: r240742 - head/sys/net X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 19:04:10 -0000 On Oct 5, 2012, at 8:50 PM, Gleb Smirnoff wrote: > On Fri, Oct 05, 2012 at 06:46:46PM +0300, Nikolay Denev wrote: > N> > On Fri, Oct 05, 2012 at 05:11:12PM +0300, Nikolay Denev wrote: > N> > N> With both modules I was able to saturate the four GigE = interfaces, and got=20 > N> > N> about ~3.72 Gbits/sec total according to iperf, systat -ifstat = showed > N> > N> about 116MB/s per each interface. > N> > N>=20 > N> > N> However I'm seeing slightly different CPU stat graphs [1], the = difference is not big, > N> > N> but with the new if_lagg(4) driver, when the machine is acting = as client I'm > N> > N> seeing slightly higher system CPU time, and about the same = interrupt, while > N> > N> when acting as server both system and interrupt are slightly = lower. > N> > N> But please note that these tests were not very scientifically = correct. > N> > N> When the server is available again I might be able to perform = several runs and > N> > N> do a proper comparison. > N> >=20 > N> > Do I understand correct, that in the above testing "server" means = transmitting > N> > traffic and "client" is receiving traffic? > N> >=20 > N> > --=20 > N> > Totus tuus, Glebius. > N>=20 > N> Actually with iperf the server is more like a sink, and the client = sends data to the server. > N> Here's what's in the man page : > N>=20 > N> To perform an iperf test the user > N> must establish both a server (to discard traffic) and a = client (to gen- > N> erate traffic). >=20 > Hmm, in this case I'm really puzzled with results. I expected that = receiving > side won't be affected and transmitting optimized. >=20 > --=20 > Totus tuus, Glebius. I have no explanation too, but I suppose my tests were flawed, as the = machine was not 100% idle at the moment of the test. I think I will have to retest with more runs, and probably use smaller = packets to stress the code more, as now iperf easily saturates the links and there is no visible speed = difference.