<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><br>Hi everyone,<br><br>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<br><br><br>test1:~$ netperf -H 192.168.1.13 -p 4000 -d -d -d<br>Program name: netperf<br>Local send alignment: 8<br>Local recv alignment: 8<br>Remote send alignment: 8<br>Remote recv alignment: 8<br>Report local CPU 0<br>Report remote CPU 0<br>Verbosity: 1<br>Debug: 3<br>Port: 4000<br>Test name: TCP_STREAM<br>Test bytes: 0 Test time: 10 Test trans: 0<br>Host name: 192.168.1.13<br><br>installing catcher for all signals<br>remotehost is 192.168.1.13 and port 4000<br>establish_control: entered with 192.168.1.13 and 4000<br>resolved the destination...
<br>creating a socket<br>about to connect<br>establish_control: connect completes<br>entered send_request...contents before htonl:<br>request contents:<br>0: 1 0 0 0 | | | | | | | |<br>4: 0 0 0 0 | | | | | | | |<br>8: 0 0
0 0 | | | | | | | |<br>12: 0 0 0 0 | | | | | | | |<br>16: 0 0 0 0 | | | | | | | |<br>20: 0 0
0 0 | | | | | | | |<br>24: 0 0 0 0 | | | | | | | |<br>28: 0 0 0 0 | | | | | | | |<br>32: 0 0
0 0 | | | | | | | |<br>36: 0 0 0 0 | | | | | | | |<br>40: 0 0 0 0 | | | | | | | |<br>44: 0 0
0 0 | | | | | | | |<br>48: 0 0 0 0 | | | | | | | |<br>52: 0 0 0 0 | | | | | | | |<br>56: 0 0
0 0 | | | | | | | |<br>60: 0 0 0 0 | | | | | | | |<br>send_request...contents after htonl:<br>request contents:<br>0: 1000000 0 0 0 | | | | | | | |<br>4: 0
0 0 0 | | | | | | | |<br>8: 0 0 0 0 | | | | | | | |<br>12: 0 0 0 0 | | | | | | | |<br>16: 0
0 0 0 | | | | | | | |<br>20: 0 0 0 0 | | | | | | | |<br>24: 0 0 0 0 | | | | | | | |<br>28: 0
0 0 0 | | | | | | | |<br>32: 0 0 0 0 | | | | | | | |<br>36: 0 0 0 0 | | | | | | | |<br>40: 0
0 0 0 | | | | | | | |<br>44: 0 0 0 0 | | | | | | | |<br>48: 0 0 0 0 | | | | | | | |<br>52: 0
0 0 0 | | | | | | | |<br>56: 0 0 0 0 | | | | | | | |<br>60: 0 0 0 0 | | | | | | | |<br><br>send_request: about to send 256 bytes from 0x805f700<br>recv_response: received a 74 byte response<br>recv_response:
partial response received: 74 bytes<br>response contents<br>0: fffb01ff fb03fffd 18fffd1f 54727969 >ÿûÿ< >ýÿû< >ýÿ< >iyrT<<br>4: 6e672030 35303532 33363136 38303032 >0 gn< >2505< >6163< >2008<<br>...< >C %e2e2e0d a252043 6f6e6e65 6374696f ><br>< >enno< >oitc<<br>12: 6e207265 66757365 64206279 2072656d >er n< >esuf< >yb d< >mer <<br>16: 6f746520 686f7374 d0a0000 0 > eto< >tsoh< > < > <<br>20: 0
0 0 0 > < > < > < > <<br>24: 0 0 0 0 > < > < > < > <<br>28: 0 0 0 0 > < > < > < >
<<br>32: 0 0 0 0 > < > < > < > <<br>36: 0 0 0 0 > < > < > < > <<br>40: 0 0 0 0 > <
> < > < > <<br>44: 0 0 0 0 > < > < > < > <<br>48: 0 0 0 0 > < > < > < > <<br>52: 0 0
0 0 > < > < > < > <<br>56: 0 0 0 0 > < > < > < > <<br>60: 0 0 0 0 > < > < > < > <<br><br><br>--- On <b>Tue, 4/14/09, Rick Jones <i><rick.jones2@hp.com></i></b>
wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Rick Jones <rick.jones2@hp.com><br>Subject: Re: [netperf-talk] Packet size<br>To: echelon360@yahoo.com<br>Cc: netperf-talk@netperf.org<br>Date: Tuesday, April 14, 2009, 11:23 AM<br><br><pre>Clive Barker wrote:<br>> hi everyone, i am hitting another bump and this time, although i'm<br>able to get something across, i continue to get the same error message while<br>sending TCP streams across<br>> <br>> any ideas please?<br>> <br>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 128 -D <br>recv_response: partial response received: 71 bytes<br>> <br>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 512 -D<br>> recv_response: partial response received: 71 bytes<br>> <br>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 10000 -D<br>> recv_response: partial response
received: 71 bytes<br>> <br>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 10000000 -D<br>> recv_response: partial response received: 71 bytes<br>> <br>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 10000000 -D<br>> recv_response: partial response received: 71 bytes<br><br>Easy bit first - make certain you have the very same version of netperf and<br>netserver running on both sides.<br><br>Also, if the reason for the non-standard control connection port number is<br>firewalls, you will also have to open a hole or holes for the data connections,<br>and use test-specific options to constrain them to specific port numbers (ones<br>other than that used for the control connection).<br><br>Finally, once the send size (-m) is greater than the MSS for the connection,<br>the -D *should* be a noop. If you see performance differences for large sends<br>with and without -D then something is arguably broken in the
stack WRT its<br>implementation of the Nagle Algorithm.<br><br>Now, if the versions match, and firewalls aren't an issue, it suggests that<br>perhaps netserver is terminating for some reason. You could enable further<br>debugging with -d on the netperf command line and look in /tmp or /var/tmp for<br>netserver log files which may include information about what is wrong. You<br>might also want to start netserver with a -d option for additonal debugging.<br><br>happy benchmarking,<br><br>rick jones<br></pre></blockquote></td></tr></table><br>