Re: TCP communication for raw image transmission

[Jean-Michel Hautbois <jhautbois@gmail.com>]

2012/1/3 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

I did it, and here are the results (when plugged directly between x86
and arm, and not throught the switch, as before) :
/ # netperf -H 192.168.0.1 -c -l 60 -t TCP_STREAM -- -m 1344 -D
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.0.1 (192.168.0.1) port 0 AF_INET : nodelay
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % U      us/KB   us/KB

 87380  16384   1344    60.01        45.43   100.00   -1.00    180.325  -1.000

And without specifying the data size :
/ # netperf -H 192.168.0.1 -c -l 60 -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.0.1 (192.168.0.1) port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % U      us/KB   us/KB

 87380  16384  16384    60.01        61.94   99.98    -1.00    132.230  -1.000

This is far better than the first tests, but this means my best bet is
to send as much data as possible (here, 16384)...
I will do a benchmark with a little script which will test several
frame sizes (or is there a way to know the theorical better value ?).

JM