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

[Rick Jones]

> Ok, now I understand!
> It seems more complicated for observing synchronization with UDP stream
> test. Here is an example of what I try:
>
> netperf -l 60 -H 10.0.17.200 -t UDP_STREAM -cC -i 10 -I 99,5 -- -m 8900 &
> netperf -l 60 -H 10.0.17.200 -t UDP_STREAM -cC -i 10 -I 99,5 -- -m 8900 &
> netperf -l 60 -H 10.0.17.200 -t UDP_STREAM -cC -i 10 -I 99,5 -- -m 8900
>
> ...
>
> Due to the protocol, the CPU utilization varies a lot. Could I only
> check the local CPU utilization in order to make sure that tests are
> running simultaneously?

I would be very careful about that.  Speaking without regard to platform 
specifics, the sending side of a UDP_STREAM test will try to consume all 
the cycles of the CPU on which it is running - there is no flow-control 
in UDP, and netperf does not try to add any.

Consider a single CPU system. If two or more netperfs are running on the 
same CPU, and one stops before the others, each netperf will still 
report 100% utilization, even though not all netperfs were running all 
the time.

Similarly, say there were four CPUs, and the three netperfs ran on two 
of them.  Two netperfs on one CPU, one netperf on a second CPU.  Assume 
one of the two netperfs on the one CPU terminated early.  The same sort 
of local CPU utilization report will happen here.  Each netperf thought 
the CPU on which it was running was at 100%, along with one of the other 
CPUs in the system.  Each will report 50% overall CPU utilization but 
they were not all running together.

Frankly the same sort of thing *can* happen with TCP-based tests, 
assuming they can take a CPU or CPUs to saturation.

> Do I need both to be near to consider UDP test
> as synchronized? I also consider the service demand which is clearly
> higher than with a single instance test.

I think you should consider switching to the "demo mode" method of 
"synchronization."  By using timestamped interim result output, one can 
post-process it to see results from when one "knows" that all N netperfs 
were running simultaneously.

You can either devise your own post-processing mechanism, or use the one 
under doc/examples in top-of-trunk.  Attached is a chart created using 
post-processing via rrdtool from a test where I hacked 
runemomniaggdemo.sh to run a UDP test, and ran it over loopback.  UDP of 
course is a little problematic over "real" networks - the netperf side 
when sending only knows what the send "speed" was, not the actual 
received speed.  If I were going to try to get a UDP "send" test for a 
single system, I'd probably run receive tests on each of the load 
generators.  That would be somewhat different script from 
runemomniaggdemo.sh - but not massively so.

> I plan to try TCP sendfile also to compare results with TCP. Does the
> size of the sent file matter?

Probably not.  All netperf will send will be that which "fits" in the 
send ring.  The send ring will be sized to be one more send than the 
size of the send socket buffer divided by the send size.

> A not related question: I try to use the -n option to choose the number
> of core used by my remote computer but this seems not to be considered.
> Does Netperf/Netserver consider this options or does it ignores it if it
> can determine itself the number of cpu?
> So, I will use CPU bind in order to do it manually.

Generally, if netperf/netserver thinks it knows how to find the number 
of CPUs, it will ignore the -n option.  Also, that is only for reporting 
CPU utilization.  It has no bearing on the number of CPUs that might be 
utilized by netperf/netserver.

happy benchmarking,

rick jones
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netperf_outbound_overall.png
Type: image/png
Size: 26227 bytes
Desc: not available
URL: <http://www.netperf.org/pipermail/netperf-talk/attachments/20120430/236f10c7/attachment-0001.png>