[netperf-talk] Issues using parallel sessions of netperf

[Rick Jones]

> > > >> Here's a sample output:
> > > >> bin/netperf -l30 -P0 -fk -t TCP_MAERTS -p14536 143.215.129.122
> > > >> bin/netperf -l30 -P0 -fk -t TCP_MAERTS -p14536 143.215.129.122
> > > >> bin/netperf -l30 -P0 -fk -t TCP_MAERTS -p14536 143.215.129.122
> 
> I actually think your problem is because you're specifying port number,
> there are some bugs in that area AFAIR.

The port number being specified is for the control port, which as near
as I can recall has been fairly solid going back quite a ways.

> I assume on the above that you forgot the -H option?

Indeed he did.  Thanks for catching that. Not entirely sure what that
will mean.  If it were not for the -P 0 then the test destination would
appear in the banner for a sanity check.

BTW, that raises a question that has been simmering in the back of my
mind.  Presently, if no-one uses a -L option, the source addressing for
the test will show IN_ADDRANY etc.  I've been wondering if netperf
should burn the CPU cycles to make a getsockname() call immediately
after the connect() call on the data connection and show that instead,
or just leave things as they are.

> maybe try a different test to fill the link?
> cd netperf-source
> ./configure --enable-burst
> make -j
> make install
> 
> this will do large receive bursts with 1 byte acks, much like normal
> stream test.

I like it when people come-up with ways to (ab)use the burst mode
functionality :)

It will be "much like normal" for some definition of much :)  Yes, the
data flow back "the other way" is tiny, but depending on the ack policy
of the stack, the sizes of request/response, and whether anyone is using
LRO/GRO, there will be (many) more "ACKs" with one byte of data with the
TCP_RR test then there would be standalone ACKs in the TCP_MAERTS test.
The throughput difference over lossless, full-duplex links is probably
epsilon most of the time, but the CPU utilization/service demand will be
higher for the RR test.

> [root at localhost ~]# netperf -t TCP_RR -l 10 -fk -H 10.23.23.181 -- -b10 -r1,64K
> TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.23.23.181 (10.23.23.181) port 0 AF_INET : first burst 10
> Local /Remote
> Socket Size   Request  Resp.   Elapsed  
> Send   Recv   Size     Size    Time     Throughput 
> bytes  Bytes  bytes    bytes   secs.    10^3bits/sec   
> 
> 16384  87380  1        65536   10.00    941194.07   
> 16384  87380 

The other side effect of using the burst-mode RR is it will effectively
put a cap on Linux's autotuning - the RR test above will never have more
than 640K of data outstanding at one time, but the TCP_MAERTS test
could, if there were no test-specific -s and/or -S options specified
have as much as 4MB outstanding at one time thanks to the autotuning.

happy benchmarking,

rick jones