Re: TCP communication for raw image transmission

[Rick Jones <rick.jones2@hp.com>]

On 01/02/2012 08:52 AM, Eric Dumazet wrote:
> Le lundi 02 janvier 2012 à 17:40 +0100, Jean-Michel Hautbois a écrit :
>
>> Mmmh, using netperf you would like to know what the client (my ARM
>> board) can do ?
>> How would you test it ? I can have an ARM board on one side, and the
>> x86 on the other...
>>
>
> x86>  netserver&
> arm>  netperf -H<arm_ip_address>  -l 60 -t TCP_STREAM
>
> 1) check cpu usage on<arm>  while test is running
> (for example : vmstat 1 )
> 2) check bandwith of test run

The "&" at the end of the netserver command is (should be) redundant - 
netserver will by default daemonize itself.

I would suggest amending the netperf command line to something more like:

netperf -H <x86IP> -c -l 60 -t TCP_STREAM -- -m <dataofoneline> -D

Which will cause netperf to make "send" calls of <dataofoneline> bytes 
(substitute dataoftwolines if you like).

The -D is to disable Nagle, which you will need to do if you really 
really want to have only one line of the picture per TCP segment.  Even 
then though, the streaming nature of TCP means you don't "really" know 
that it will go out that way onto the network.  Otherwise, leave it off 
and TCP will attempt to aggregate the sends into maximum segment sized 
segments.

The -c is to get netperf to report CPU utilization for the local/netperf 
side.

As Eric suggests, you really should just hand as much data to TCP at one 
time as you reasonably can within the constraints of the rest of your 
application

Skipping ahead a little, on the netperf side at least you might be well 
served to do:

netstat -s > before
netperf ....
netstat -s > after
beforeafter before after > delta

and then run "before" and "after" through "beforeafter" from 
ftp://ftp.cup.hp.com/dist/networking/tools or something similar - I 
think someone (here on netdev?) created a more robust version at some 
point.  Alas, beforeafter will sometimes get confused if a new statistic 
appears in after that was not present in before - the utility was 
initially developed on HP-UX, the netstat of which does not have the 
"only display non-zero values" mindset.

One other thing - your 100 Mbit/s link - is that full duplex or half? 
If half you may need to be concerned with "capture effect."  Briefly, it 
was a CSMA/CD behaviour which emerged once systems were fast enough to 
saturate the Ethernet link - the transmitting station would "capture" 
the wire (half-duplex) and the receiving station, which was still trying 
to transmit ACKs would end-up backing-off (at the PHY/data link).  Then 
the transmitter would stop transmitting, having run-out of window, but 
the receiver's NIC would still be backed-off and so the link would go 
idle.  The workaround was to either have a rather large or rather small 
(8KB, IIRC but best do some web searchings - this topic goes back to the 
1990s) TCP window.

happy benchmarking,

rick jones