[netperf-talk] Problem with Bidirectional Test

[Ankit Goyal]

Thanks a ton guys!!

If possible could you tell me that how much max bidirectional throughput I
can get on 1Gbps ethernet connection?Can I get more than 1 Gig by changing
the drivers and kernel?
I know its a very relative question but i will be glad if u help me out!

thanks

On Tue, Jul 7, 2009 at 6:00 PM, Rick Jones <rick.jones2 at hp.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.netperf.org/pipermail/netperf-talk/attachments/20090709/1544f16c/attachment.htm