netdev - Re: TCP communication for raw image transmission

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Jan 2012 10:13:32 +0100
From:	Jean-Michel Hautbois <jhautbois@...il.com>
To:	Rick Jones <rick.jones2@...com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: TCP communication for raw image transmission

2012/1/3 Rick Jones <rick.jones2@...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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html