care and feeding of netperf (Re: Mainline kernel OLTP performance update)

3) ./start_netperf_udp_v4.sh 8 #Assume your machine has 8 logical cpus.

Some comments on the script:

#!/bin/sh

PROG_DIR=/home/ymzhang/test/netperf/src
date=`date +%H%M%N`
#PROG_DIR=/root/netperf/netperf/src
client_num=$1
pin_cpu=$2

start_port_server=12384
start_port_client=15888

killall netserver
${PROG_DIR}/netserver
sleep 2

Any particular reason for killing-off the netserver daemon?

if [ ! -d result ]; then
mkdir result
fi

all_result_files=""
for i in `seq 1 ${client_num}`; do
if [ "${pin_cpu}" == "pin" ]; then
pin_param="-T ${i} ${i}"

The -T option takes arguments of the form:

N - bind both netperf and netserver to core N
N, - bind only netperf to core N, float netserver
,M - float netperf, bind only netserver to core M
N,M - bind netperf to core N and netserver to core M

Without a comma between N and M knuth only knows what the command line parser will do :)

fi
result_file=result/netperf_${start_port_client}.${date}
#./netperf -t UDP_STREAM -l 60 -H 127.0.0.1 -- -P 15895 12391 -s 32768 -S 32768 -m 4096
#./netperf -t UDP_STREAM -l 60 -H 127.0.0.1 -i 50 3 -I 99 5 -- -P 12384 12888 -s 32768 -S 32768 -m 4096
#${PROG_DIR}/netperf -p ${port_num} -t TCP_RR -l 60 -H 127.0.0.1 ${pin_param} -- -r 1,1 >${result_file} &
${PROG_DIR}/netperf -t UDP_STREAM -l 60 -H 127.0.0.1 ${pin_param} -- -P ${start_port_client} ${start_port_server} -s 32768 -S 32768 -m 4096 >${result_file} &

Same thing here for the -P option - there needs to be a comma between the two port numbers otherwise, the best case is that the second port number is ignored. Worst case is that netperf starts doing knuth only knows what.


To get quick profiles, that form of aggregate netperf is OK - just the one iteration with background processes using a moderatly long run time. However, for result reporting, it is best to (ab)use the confidence intervals functionality to try to avoid skew errors. I tend to add-in a global -i 30 option to get each netperf to repeat its measurments 30 times. That way one is reasonably confident that skew issues are minimized.

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

And I would probably add the -c and -C options to have netperf report service demands.


sub_pid="${sub_pid} `echo $!`"
port_num=$((${port_num}+1))
all_result_files="${all_result_files} ${result_file}"
start_port_server=$((${start_port_server}+1))
start_port_client=$((${start_port_client}+1))
done;

wait ${sub_pid}
killall netserver

result="0"
for i in `echo ${all_result_files}`; do
sub_result=`awk '/Throughput/ {getline; getline; getline; print " "$6}' ${i}`
result=`echo "${result}+${sub_result}"|bc`
done;

The documented-only-in-source :( "omni" tests in top-of-trunk netperf:

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

./configure --enable-omni

allow one to specify which result values one wants, in which order, either as more or less traditional netperf output (test-specific -O), CSV (test-specific -o) or keyval (test-specific -k). All three take an optional filename as an argument with the file containing a list of desired output values. You can give a "filename" of '?' to get the list of output values known to that version of netperf.

Might help simplify parsing and whatnot.

happy benchmarking,

rick jones


echo $result



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: care and feeding of netperf (Re: Mainline kernel OLTP performance update)
    ... Any particular reason for killing-off the netserver daemon? ... N - bind both netperf and netserver to core N ...
    (Linux-Kernel)
  • Re: strange TCP/IP results
    ... or some similar connectivity issue; I'd try to run some diagnostics ... just be sure to get both the netperf and the netserver binaries, ... the other (pointing it to the netserver address) this should give you ... Microsoft MVP: Windows Server - Networking ...
    (microsoft.public.windows.server.networking)
  • Re: strange TCP/IP results
    ... > downloading the netperf binaries for windows from this site ... > just be sure to get both the netperf and the netserver binaries, ... > the other (pointing it to the netserver address) this should give you ... > Microsoft MVP: Windows Server - Networking ...
    (microsoft.public.windows.server.networking)
  • Re: [tbench regression fixes]: digging out smelly deadmen.
    ... or netserver to a specific CPU might help cut-down the variables. ... FWIW netperf top of trunk omni tests can now also determine and report the state of SELinux. ...
    (Linux-Kernel)
Loading