<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">thanks again!<br><br>I'm unable to make use of any of the command options mentioned below.<br>However, i did an md5sum on both netperf binaries and they are a match so i'm hoping that is an adequate confirmation.<br><br>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:<br><br>test1:~$ netperf -H 192.168.1.13 -p 4000<br>TCP STREAM TEST to 192.168.1.13<br>netperf: send_tcp_stream: data socket connect failed: Connection refused<br> port: 32791<br><br>does this relate to the fact that the linux host do not allow receiving data on this ports.<br>There are no firewalls between the two devices.<br><br>--- On <b>Thu, 4/16/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: Thursday, April 16, 2009, 3:57 PM<br><br><pre>Clive Barker wrote:<br>> <br>> Hi everyone,<br>> <br>> I've increased the debugging on this to validate why i'm still<br>hitting the same issue. Below is the capture. I guess the next obvious thing was<br>to check the version of netperf running on both machines.Is there a command<br>string i can use to extract this? I'm pretty sure both are 2.4.4<br><br>If you are running a new-enough netperf/netserver you can run:<br><br>netperf -V<br><br>and<br><br>netserver -V<br><br>otherwise, since I am an old-time mneomic memory circuits from stone knives and<br>bearskins kind of guy, both binaries should have "what strings" in<br>them so if you have a what command you can do:<br><br>what
netperf<br>what netserver<br><br>if you don't have a what command, I think you can simulated it with a<br>combination of strings and grep:<br><br>strings netperf | fgrep "@(#)" - take the highest version you can see<br>- don't be surprised if netperf -V and the what strings are not in complete<br>agreement though...<br><br>rick jones<br><br><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>|<br>> 8: 0 0 0 0 | | | | | | | <br>|<br>> 12: 0 0 0 0 | | | | | | | <br>|<br>> 16: 0 0 0 0 | | | | | | | <br>|<br>> 20: 0 0 0 0 | | | | | | | <br>|<br>> 24: 0 0 0 0 | | | | | | | <br>|<br>> 28: 0 0 0 0 | | | | | | | <br>|<br>> 32: 0 0 0 0 |
| | | | | | <br>|<br>> 36: 0 0 0 0 | | | | | | | <br>|<br>> 40: 0 0 0 0 | | | | | | | <br>|<br>> 44: 0 0 0 0 | | | | | | | <br>|<br>> 48: 0 0 0 0 | | | | | | | <br>|<br>> 52: 0 0 0 0 | | | | | | | <br>|<br>> 56: 0 0 0 0 | | | | | | | <br>|<br>> 60: 0 0 0 0 | | | | | | | <br>|<br>> send_request...contents after htonl:<br>> request contents:<br>> 0: 1000000 0 0 0 | | | | | | | <br>|<br>> 4: 0 0 0 0 | | | | | | | <br>|<br>> 8: 0 0 0 0 | | | | | | |
<br>|<br>> 12: 0 0 0 0 | | | | | | | <br>|<br>> 16: 0 0 0 0 | | | | | | | <br>|<br>> 20: 0 0 0 0 | | | | | | | <br>|<br>> 24: 0 0 0 0 | | | | | | | <br>|<br>> 28: 0 0 0 0 | | | | | | | <br>|<br>> 32: 0 0 0 0 | | | | | | | <br>|<br>> 36: 0 0 0 0 | | | | | | | <br>|<br>> 40: 0 0 0 0 | | | | | | | <br>|<br>> 44: 0 0 0 0 | | | | | | | <br>|<br>> 48: 0 0 0 0 | | | | | | | <br>|<br>> 52: 0 0 0 0 | | | | | | |
<br>|<br>> 56: 0 0 0 0 | | | | | | | <br>|<br>> 60: 0 0 0 0 | | | | | | | <br>|<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 >ÿûÿ<<br>>ýÿû< >ýÿ< >iyrT<<br>> 4: 6e672030 35303532 33363136 38303032 >0 gn< >2505<<br>>6163< >2008<<br>> ...< >C %e2e2e0d a252043 6f6e6e65 6374696f ><br>> < >enno< >oitc<<br>> 12: 6e207265 66757365 64206279 2072656d >er n< >esuf<<br>>yb d< >mer <<br>> 16: 6f746520 686f7374 d0a0000 0 > eto< >tsoh<<br>> < > <<br>> 20: 0
0 0 0 > < > <<br>> < > <<br>> 24: 0 0 0 0 > < > <<br>> < > <<br>> 28: 0 0 0 0 > < > <<br>> < > <<br>> 32: 0 0 0 0 > < > <<br>> < > <<br>> 36: 0 0 0 0 > < > <<br>> < > <<br>> 40: 0 0 0 0 > < > <<br>> < > <<br>> 44: 0 0 0 0 > < > <<br>> < > <<br>> 48: 0 0 0 0 > < > <<br>> < > <<br>> 52: 0 0 0 0 > < > <<br>> < >
<<br>> 56: 0 0 0 0 > < > <<br>> < > <<br>> 60: 0 0 0 0 > < > <<br>> < > <<br>> <br>> <br>> --- On *Tue, 4/14/09, Rick Jones /<rick.jones2@hp.com>/* wrote:<br>> <br>> 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>> 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<br>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<br>> received: 71 bytes<br>>> <br>>> test1:~$ netperf -H 192.168.1.13 -p 4000 -t TCP_STREAM -- -m 10000000<br>-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<br>-D<br>>> recv_response: partial response received: 71 bytes<br>> <br>> Easy bit first - make certain you have the very same version of netperf<br>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<br>connections,<br>> and use test-specific options to constrain them to specific port numbers<br>(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<br>connection,<br>> the -D *should* be a noop. If you see performance differences for large<br>sends<br>> with and without -D then something is arguably broken in the<br>> stack WRT its<br>> implementation of the Nagle Algorithm.<br>> <br>> Now, if the versions match, and firewalls aren't an issue, it suggests<br>that<br>> perhaps netserver is terminating for some reason. You could enable<br>further<br>> debugging with -d on the netperf command line and look in /tmp or /var/tmp<br>for<br>> netserver log files which may include information about what is wrong. <br>You<br>> might also want to start netserver with a -d option for
additonal<br>debugging.<br>> <br>> happy benchmarking,<br>> <br>> rick jones<br>> <br>> <br><br></pre></blockquote></td></tr></table><br>