[netperf-talk] multithread support and other feature ideas

[Rick Jones]

Brandeburg, Jesse wrote:
> in these days of multicore systems, what is the state of multithreaded netperf?

that would be netperf4:

http://www.netperf.org/svn/netperf4/trunk

which could use some help.  It presently suffers/benefits from a very rich 
configuration file mechanism and dependencies on glib and libxml2.  I find I am 
most able to work-on/enhance netperf2 when others are actively involved - helps 
get me off my keyster :)

> also, one of the coolest features of the old ttcp was that it had a polynomial
> based traffic generator mode for detecting data corruption.
> 
> it was cool because the polynomial only repeated the same data pattern every
> 2^something huge bytes, which made it easy to predict the value of any given
> byte at the other end, and made detecting single byte data corruption simple.
> 
> I'm not sure if the polynomial thing would be part of netperf's charter or
> not, 

I've wanted to avoid netperf being corrupted into a functional test :)  Still, 
there is the global -F option which will cause netperf's buffers to be filled 
with data from the specified file.  However, netperf/netserver will not attempt 
to determine if there was data corruption - the mechanism was put into place to 
allow netperf to send uncompressible data when necessary.

By default, top-of-trunk netperf:

http://www.netperf.org/svn/netperf2/trunk

tries to put a repeating "netperf " into what it sends.  This was done to allow 
someone sniffing traffic to more easily see if something was a netperf flow. 
Seems that at some point, someone using the UDP_STREAM test didn't check their 
routing and ended-up flooding a site-to-site link and took-out the security 
camera feeds... I ended-up getting a phone call from some IT folks asking if 
there was anyway netperf could prevent such things - I tossed them "netperf " in 
the data stream but reminded them that netperf cannot fix end-system routing 
errors :)

> but multithreading should be if at all possible.
> 
> right now I multithread netperf like so:
> 
> for ((i=1; i<17; i++)); do netperf -H 10.0.0.$i -t TCP_STREAM -C -c -P0 & done
> 
> however I don't get aggregate throughput unless I script up a bunch of
> awk/sed/bash addition magic.
> 
> Thoughts?

Short term I would suggest following:

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

particularly the bit about (ab)using the confidence intervals to help detect skew 
errors.

Medium term I might suggest the netperf2 "omni" tests - not so much because they 
will one day replace the scattershot code for TCP, UDP, SDP DCCP etc, but because 
they introduce the ability to get netperf to emit not only classic-esque "Human" 
output, but CSV and keyval, and you can configure what netperf emits specifically 
via what are currently a "-t omni" test-specific -O (human) -o (CSV) or -k 
(keyval) option.  If you pass a ? to either of those they will emit the list of 
known outputs.  You can then make a list of those you want in a file and pass 
that to the option instead:

netperf -H <remote> -t omni -- -o foo

It won't eliminate the post processing, but it might make it easier. (just as you 
do now, you have to remember that each netperf is reporting overall system CPU 
util and caculating service demand based on that)

On those platforms with support, netperf2 omni tests will attempt to find things 
like the presumed egress interface, driver name and revision for same, PCI slot 
number, system kernel revision, etc etc.  It can also be asked to report not just 
the overall CPU utilization, but the ID and utilization of the most utilized CPU

happy benchmarking,

rick jo nes