[netperf-talk] Packet size
Clive Barker
echelon360 at yahoo.com
Tue Apr 21 18:27:37 PDT 2009
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.
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.
--- 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.netperf.org/pipermail/netperf-talk/attachments/20090421/f2f8aa68/attachment.html
More information about the netperf-talk
mailing list