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]

Message-ID: <4F05EECE.1000708@hp.com>
Date:	Thu, 05 Jan 2012 10:41:18 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Jean-Michel Hautbois <jhautbois@...il.com>, netdev@...r.kernel.org
Subject: Re: TCP communication for raw image transmission

On 01/05/2012 02:04 AM, Eric Dumazet wrote:
> Le jeudi 05 janvier 2012 à 10:57 +0100, Jean-Michel Hautbois a écrit :
>>   # netperf -H 192.168.0.1 -c -l 10 -t UDP_STREAM -- -m 1500
>> MIGRATED UDP 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
>> Socket  Message  Elapsed      Messages                   CPU      Service
>> Size    Size     Time         Okay Errors   Throughput   Util     Demand
>> bytes   bytes    secs            #      #   10^6bits/sec % SU     us/KB
>>
>> 106496    1500   10.00       54477      0        0.0     65.34    100.000
>> 1073741824           2.25            0               0.0     65.34    -1.000
>>
>
> Hmm... this sounds you have half duplex somewhere ?

Why?  A netperf UDP_STREAM test is "purely" unidirectional (*).  I 
suspect the numbers look funny thanks to the 32-bit compilation bugs 
(format statement issues).

Apart from updating to the top of trunk bits from 
http://www.netperf.org/svn/netperf2/trunk , another way to run the test 
with the existing bits would be to get the explicit "omni" output going 
with something akin to:

netperf -H 192.168.0.1 -t omni -c -l 10 -- -T UDP -m 1500

raj@...dy:~/netperf2_trunk$ src/netperf -t omni -H localhost -c -l 10 -- 
-T udp -m 1500
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
localhost.localdomain () port 0 AF_INET
Local       Local       Local Elapsed Throughput Throughput  Local 
Local  Remote Remote Local   Remote  Service
Send Socket Send Socket Send  Time               Units       CPU    CPU 
    CPU    CPU    Service Service Demand
Size        Size        Size  (sec)                          Util   Util 
   Util   Util   Demand  Demand  Units
Final       Final                                            % 
Method %      Method
1254744     1254744     1500  10.00   12869.82   10^6bits/s  42.05  S 
    -1.00  U      1.071   -1.000  usec/KB

Or to avoid the wraps, use the keyval output format:

raj@...dy:~/netperf2_trunk$ src/netperf -t omni -H localhost -c -l 10 -- 
-T udp -m 1500 -k
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
localhost.localdomain () port 0 AF_INET
LSS_SIZE_END=1390392
LSS_SIZE_END=1390392
LOCAL_SEND_SIZE=1500
ELAPSED_TIME=10.00
THROUGHPUT=12640.22
THROUGHPUT_UNITS=10^6bits/s
LOCAL_CPU_UTIL=41.19
LOCAL_CPU_METHOD=S
REMOTE_CPU_UTIL=-1.00
REMOTE_CPU_METHOD=U
LOCAL_SD=1.068
REMOTE_SD=-1.000
SD_UNITS=usec/KB

One could also whittle the output down by using the omni output 
selectors - 
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Omni-Output-Selection

rick jones

* well, there may be a stray, delayed TCP ACKnowledgement on the control 
connection while the UDP traffic is flowing, but even that I believe 
will be from netperf to netserver - ie in the direction the UDP_STREAM 
traffic is going
--
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