[netperf-talk] Packet size
Clive Barker
echelon360 at yahoo.com
Thu Apr 16 15:27:38 PDT 2009
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
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/20090416/33344882/attachment.htm
More information about the netperf-talk
mailing list