[netperf-talk] Packet size

[Rick Jones]

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