[netperf-talk] Packet size
Rick Jones
rick.jones2 at hp.com
Thu Apr 16 15:57:37 PDT 2009
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