[netperf-talk] global question concerning Netperf test and SMP support

[Rick Jones]

On 04/04/2012 03:15 AM, Simon Duboue wrote:
>
> Could the total throughput be considered as the sum of the two obtained
> results?

Maybe :)  There is no explicit synchronization in netperf.  There are a 
few ways to address issues of skew error:

http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Using-Netperf-to-Measure-Aggregate-Performance

The one I currently use the most is the "demo mode with post-processing" 
path, though that has an issue with UDP_STREAM - the interim results 
reported by netperf in a UDP_STREAM test will be sender side, not 
receiver side.  In that case the (ab)use of confidence intervals path 
may be better (though take longer).

While the local CPU util in your pair of UDP_STREAM tests was the same, 
the remote CPU util differed enough that I would not trust the results 
to have low skew error.

> If so, what could be the limitations of the single process throughput?
> It seems that the two processes are running in parallel according to the
> top command and to the system performance tool.

Service demand versus available cycles. Or put another way, the stack's 
effective path length versus the instruction rate of the processor(s).

Broadly speaking a single TCP connection or UDP flow cannot take 
advantage of the services of more than one "CPU" (core/hw thread).  A 
single netperf instance will be a single connection/flow.  So, even if 
you have multiple cores in the system, one of them may have saturated, 
and that will limit things.

You can either watch with top running at the same time, or ask netperf 
to emit 
local_cpu_peak_util,local_cpu_peak,id,remote_cpu_peak_util,remote_cpu_peak_id 
via the omni output selection mechanism.

Now, when you were running two concurrent netperfs,  assuming netperf is 
running on the 8 core system, I'm surprised that it went to 100% CPU 
util on the TCP test - I would have expected no more than 50%, with four 
cores saturated (sometimes netperf/netserver can end-up running on 
something other than the interrupt CPUs) - but that may be the effect of 
the NIC interrupts going to all cores together rather than being 
smp_affinitied to specific CPUs.

rick jones