[netperf-talk] Packet size
Rick Jones
rick.jones2 at hp.com
Wed Apr 22 10:15:40 PDT 2009
Clive Barker wrote:
> thanks again!
>
> I'm unable to make use of any of the command options mentioned below.
> However, i did an md5sum on both netperf binaries and they are a match
> so i'm hoping that is an adequate confirmation.
If the -V option is not supported in your binaries, it implies they are not "the
latest" - not necessarily bad, just "not the latest" :)
>
> I have made some amendments to the x25 routing statements and this time,
> i can see a TCP session established between client and server but the
> error i'm getting back from the client is:
>
> test1:~$ netperf -H 192.168.1.13 -p 4000
> TCP STREAM TEST to 192.168.1.13
> netperf: send_tcp_stream: data socket connect failed: Connection refused
> port: 32791
>
> does this relate to the fact that the linux host do not allow receiving
> data on this ports.
> There are no firewalls between the two devices.
Is there a firewall on the end system(s)?
rick jones
>
> --- On *Thu, 4/16/09, Rick Jones /<rick.jones2 at hp.com>/* wrote:
>
> From: Rick Jones <rick.jones2 at hp.com>
> Subject: Re: [netperf-talk] Packet size
> To: echelon360 at yahoo.com
> Cc: netperf-talk at netperf.org
> Date: Thursday, April 16, 2009, 3:57 PM
>
> Clive Barker wrote:
>>
>> Hi everyone,
>>
>> I've increased the debugging on this to validate why i'm still
> hitting the same issue. Below is the capture. I guess the next obvious thing was
> to check the version of netperf running on both machines.Is there a command
> string i can use to extract this? I'm pretty sure both are 2.4.4
>
> If you are running a new-enough netperf/netserver you can run:
>
> netperf -V
>
> and
>
> netserver -V
>
> otherwise, since I am an old-time mneomic memory circuits from stone knives and
> bearskins kind of guy, both binaries should have "what strings" in
> them so if you have a what command you can do:
>
> what
> netperf
> what netserver
>
> if you don't have a what command, I think you can simulated it with a
> combination of strings and grep:
>
> strings netperf | fgrep "@(#)" - take the highest version you can see
> - don't be surprised if netperf -V and the what strings are not in complete
> agreement though...
>
> rick jones
>
>
>>
>>
>> test1:~$ netperf -H 192.168.1.13 -p 4000 -d -d -d
>> Program name: netperf
>> Local send alignment: 8
>> Local recv alignment: 8
>> Remote send alignment: 8
>> Remote recv alignment: 8
>> Report local CPU 0
>> Report remote CPU 0
>> Verbosity: 1
>> Debug: 3
>> Port: 4000
>> Test name: TCP_STREAM
>> Test bytes: 0 Test time: 10 Test trans: 0
>> Host name: 192.168.1.13
>>
>> installing catcher for all signals
>> remotehost is 192.168.1.13 and port 4000
>> establish_control: entered with 192.168.1.13 and
> 4000
>> resolved the destination...
>> creating a socket
>> about to connect
>> establish_control: connect completes
>> entered send_request...contents before htonl:
>> request contents:
>> 0: 1 0 0 0 | | | | | | | |
>> 4: 0 0 0 0 | | | | | | |
> |
>> 8: 0 0 0 0 | | | | | | |
> |
>> 12: 0 0 0 0 | | | | | | |
> |
>> 16: 0 0 0 0 | | | | | | |
> |
>> 20: 0 0 0 0 | | | | | | |
> |
>> 24: 0 0 0 0 | | | | | | |
> |
>> 28: 0 0 0 0 | | | | | | |
> |
>> 32: 0 0 0 0 |
> | | | | | |
> |
>> 36: 0 0 0 0 | | | | | | |
> |
>> 40: 0 0 0 0 | | | | | | |
> |
>> 44: 0 0 0 0 | | | | | | |
> |
>> 48: 0 0 0 0 | | | | | | |
> |
>> 52: 0 0 0 0 | | | | | | |
> |
>> 56: 0 0 0 0 | | | | | | |
> |
>> 60: 0 0 0 0 | | | | | | |
> |
>> send_request...contents after htonl:
>> request contents:
>> 0: 1000000 0 0 0 | | | | | | |
> |
>> 4: 0 0 0 0 | | | | | | |
> |
>> 8: 0 0 0 0 | | | | | | |
>
> |
>> 12: 0 0 0 0 | | | | | | |
> |
>> 16: 0 0 0 0 | | | | | | |
> |
>> 20: 0 0 0 0 | | | | | | |
> |
>> 24: 0 0 0 0 | | | | | | |
> |
>> 28: 0 0 0 0 | | | | | | |
> |
>> 32: 0 0 0 0 | | | | | | |
> |
>> 36: 0 0 0 0 | | | | | | |
> |
>> 40: 0 0 0 0 | | | | | | |
> |
>> 44: 0 0 0 0 | | | | | | |
> |
>> 48: 0 0 0 0 | | | | | | |
> |
>> 52: 0 0 0 0 | | | | | | |
>
> |
>> 56: 0 0 0 0 | | | | | | |
> |
>> 60: 0 0 0 0 | | | | | | |
> |
>>
>> send_request: about to send 256 bytes from 0x805f700
>> recv_response: received a 74 byte response
>> recv_response: partial response received: 74 bytes
>> response contents
>> 0: fffb01ff fb03fffd 18fffd1f 54727969 >ÿûÿ<
>>ýÿû< >ýÿ< >iyrT<
>> 4: 6e672030 35303532 33363136 38303032 >0 gn< >2505<
>>6163< >2008<
>> ...< >C %e2e2e0d a252043 6f6e6e65 6374696f >
>> < >enno< >oitc<
>> 12: 6e207265 66757365 64206279 2072656d >er n< >esuf<
>>yb d< >mer <
>> 16: 6f746520 686f7374 d0a0000 0 > eto< >tsoh<
>> < > <
>> 20: 0
> 0 0 0 > < > <
>> < > <
>> 24: 0 0 0 0 > < > <
>> < > <
>> 28: 0 0 0 0 > < > <
>> < > <
>> 32: 0 0 0 0 > < > <
>> < > <
>> 36: 0 0 0 0 > < > <
>> < > <
>> 40: 0 0 0 0 > < > <
>> < > <
>> 44: 0 0 0 0 > < > <
>> < > <
>> 48: 0 0 0 0 > < > <
>> < > <
>> 52: 0 0 0 0 > < > <
>> < >
> <
>> 56: 0 0 0 0 > < > <
>> < > <
>> 60: 0 0 0 0 > < > <
>> < > <
>>
>>
>> --- On *Tue, 4/14/09, Rick Jones /<rick.jones2 at hp.com>/* wrote:
>>
>> From: Rick Jones <rick.jones2 at hp.com>
>> Subject: Re: [netperf-talk] Packet size
>> To: echelon360 at yahoo.com
>> Cc: netperf-talk at netperf.org
>> Date: Tuesday, April 14, 2009, 11:23 AM
>>
>> Clive Barker wrote:
>>> hi everyone, i am hitting another bump and this time, although i'm
>> able to get something across, i continue to get the same error message
> while
>> sending TCP streams across
>>>
>>> any ideas please?
>>>
>>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 128 -D
>>
> recv_response: partial response received: 71 bytes
>>>
>>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 512 -D
>>> recv_response: partial response received: 71 bytes
>>>
>>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 10000 -D
>>> recv_response: partial response
>> received: 71 bytes
>>>
>>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 10000000
> -D
>>> recv_response: partial response received: 71 bytes
>>>
>>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 10000000
> -D
>>> recv_response: partial response received: 71 bytes
>>
>> Easy bit first - make certain you have the very same version of netperf
> and
>> netserver running on both sides.
>>
>> Also, if the reason for the non-standard control connection port number is
>> firewalls, you will also
> have to open a hole or holes for the data
> connections,
>> and use test-specific options to constrain them to specific port numbers
> (ones
>> other than that used for the control connection).
>>
>> Finally, once the send size (-m) is greater than the MSS for the
> connection,
>> the -D *should* be a noop. If you see performance differences for large
> sends
>> with and without -D then something is arguably broken in the
>> stack WRT its
>> implementation of the Nagle Algorithm.
>>
>> Now, if the versions match, and firewalls aren't an issue, it suggests
> that
>> perhaps netserver is terminating for some reason. You could enable
> further
>> debugging with -d on the netperf command line and look in /tmp or /var/tmp
> for
>> netserver log files which may include information about what is wrong.
> You
>> might also want to start netserver with a -d option for
> additonal
> debugging.
>>
>> happy benchmarking,
>>
>> rick jones
>>
>>
>
>
More information about the netperf-talk
mailing list