| 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
| ||
|
Date: Thu, 05 Jan 2012 10:40:10 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: Jean-Michel Hautbois <jhautbois@...il.com> Cc: Rick Jones <rick.jones2@...com>, netdev@...r.kernel.org Subject: Re: TCP communication for raw image transmission Le jeudi 05 janvier 2012 à 10:13 +0100, Jean-Michel Hautbois a écrit : > 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 ?). > Could you test UDP_STREAM as well ? $ netperf -H 192.168.0.1 -l 10 -t UDP_STREAM UDP UNIDIRECTIONAL SEND 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 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 1000000 65507 10.00 13398 0 702.12 110592 10.00 13398 702.12 Then, a pktgen test (this sends UDP frames, but from kernel land) might give you the limit of the NIC... -- 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
Powered by blists - more mailing lists