[netperf-talk] Problem with Bidirectional Test

Rick Jones rick.jones2 at hp.com
Tue Jul 7 10:00:38 PDT 2009


Brandeburg, Jesse wrote:
> netperf –t TCP_RR –C –c -- -r 64K –b5

This will give a single-connection bidirectional test - IFF netperf have been 
./configure'd with --enable-burst

> *From:* netperf-talk-bounces at netperf.org 
> [mailto:netperf-talk-bounces at netperf.org] *On Behalf Of *Ankit Goyal
> *Sent:* Tuesday, July 07, 2009 7:40 AM
> *To:* netperf-talk at netperf.org
> *Subject:* [netperf-talk] Problem with Bidirectional Test
>
> Hi,
> 
> I am trying to find out the bi-directional throughput through netperf-2.4.5.
> But when i write this code:
> 
> for i in 1
> do
> ./netperf -H mycomputer -t TCP_STREAM -B "outbound" 
> ./netperf -H mycomputer -t TCP_MAERTS -B "inbound" 
> 
> done
> 
> so this command TCP_MAERTS does not work
> 
> It says *netperf:remote error 998*
> 
> this error is dispayed on my board.
> 
> How is the best way to check the bi-directional throughput? please let 
> me know asap

I am assuming the for loop above is missing the "&" after each of the netperf 
commands because you didn't bring them over into the email.  Otherwise, the 
first problem is that those commands as shown in the email will operate in 
series (one after the other) rather than in parallel.

As for the 998 error, one first step would be to grep through the sources with 
something like:

raj at tardy:~/netperf2_trunk/src$ find . -exec grep 998 {} \;
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
       netperf_response.content.serv_errno=998;
** Copyright (c) 1998 Microsoft.
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
dnl Copyright (c) 1995, 1996, 1997, 1998
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
dnl Copyright (c) 1995, 1996, 1997, 1998
dnl Copyright (c) 1995, 1996, 1997, 1998
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
       netperf_response.content.serv_errno=998;
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
       netperf_response.content.serv_errno=998;

of course that finds lots of things besides the 998 error code, but if we refine 
the search to:

raj at tardy:~/netperf2_trunk/src$ find . -exec grep "=998" {} \;
       netperf_response.content.serv_errno=998;
       netperf_response.content.serv_errno=998;
       netperf_response.content.serv_errno=998;

and then ask for the filenames:

raj at tardy:~/netperf2_trunk/src$ find . -exec grep -l "=998" {} \;
./.svn/text-base/netserver.c.svn-base
./netserver.c
./netserver.c~

and then go into netserver.c (ok, I could have done that straight away, but I'm 
trying to give a fishing lesson :) we find:

     default:
       fprintf(where,"unknown test number %d\n",
               netperf_request.content.request_type);
       fflush(where);
       netperf_response.content.serv_errno=998;
       send_response();
       break;


which suggests the netserver running on "mycomputer" is old enough it does not 
know about the TCP_MAERTS test.  While mismatched versions between netperf and 
netserver have often "worked" they have never been "supported" and so you must 
update the netserver on "mycomputer" to the same rev as netperf.  Ideally, in 
doing so you would be bringing both netperf and netserver to version 2.4.5.

Now, as for which is "better" - the single connection burst-mode TCP_RR 
bidirectional test or the parallel TCP_STREAM and TCP_MAERTS tests, that is 
another of a long series of "it depends" questions.

The single-connection test will more or less by definition "balance" send and 
receive - just by the way it is coded.  It will also only make use of the 
services of one core/thread in the processor(s) on the system (*).

The dual-connection test will not lock send and recv into balance.  There will 
be two competing threads of execution running and so the services of up to two 
cores/threads in the processor(s) will be employed (*).  There is also the issue 
of skew error since netperf2 has no explicit test shynchronization.  To 
workaround that you would probably need to further alter the command lines to be 
more like:

for i in 1
do
./netperf -i 30 -l 30 -H mycomputer -t TCP_STREAM -B "outbound" &
./netperf -i 30 -l 30 -H mycomputer -t TCP_MAERTS -B "inbound" &
done

The -i 30 optionwill force each netperf command to run the test 30 times.  The 
-l 30 option will have each of those thiry iterations run for 30 seconds.  This 
then helps make certain that the length of any startup and shutdown skew is 
minimized relative to the actual time measurements are happening.  The -i 30 
option will also cause netperf to check confidence intervals.  If they are not 
met, netperf will emit a warning and you might consider increasing the value in 
the -l option.

happy benchmarking,

rick jones

(*) unless, perhaps one binds netperf/netserver to cores/threads other than 
those taking interrupts from the NIC(s). In that case, a single connection can 
make use of the services of up to two cores/threads and two connections up to 
three.  Even then there is some wriggle room if say link aggregation is in use 
of some other mechanism to cause interrupts from the NIC(s) to go to more than 
one core/thread in the system.


More information about the netperf-talk mailing list