svn commit: r240742 - head/sys/net

[Nikolay Denev]

On Oct 5, 2012, at 8:50 PM, Gleb Smirnoff <glebius at FreeBSD.org> 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 
> N> > N> about ~3.72 Gbits/sec total according to iperf, systat -ifstat showed
> N> > N> about 116MB/s per each interface.
> N> > N> 
> 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> > 
> N> > Do I understand correct, that in the above testing "server" means transmitting
> N> > traffic and "client" is receiving traffic?
> N> > 
> N> > -- 
> N> > Totus tuus, Glebius.
> N> 
> 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> 
> 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).
> 
> Hmm, in this case I'm really puzzled with results. I expected that receiving
> side won't be affected and transmitting optimized.
> 
> -- 
> 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.