[netperf-talk] 802.11g udp and tcp bandwidth test

[Max Ip]

Yah, thats true there should be some back traffic in UDP_STREAM test.
To caculate the UPD throughput between two 802.11g enabled network, I
configured netserver in 192.168.1.4 and I ran the following in netperf
(192.168.1.2).

netperf -H 192.168.1.4 -c -C -t UDP_STREAM -- -s 54M -S 54M -m 1024
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.4 (192.168.1.4) port 0 AF_INET : demo
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

262142    1024   10.00       27615      0       22.6     9.40     68.154
262142           10.00       27594              22.6     0.40     2.935


When I changed the value of -m to 2048, the throughput increased as follows:

netperf -H 192.168.1.4 -c -C -t UDP_STREAM -- -s 54M -S 54M -m 2048
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.4 (192.168.1.4) port 0 AF_INET : demo
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

262142    2048   10.00       15013      0       24.6     6.50     43.313
262142           10.00       15013              24.6     0.41     2.698

So, the throughput increased from 22.6 ko 24.6Mbps.

As rick said, the value of -m should be more than MTU for 802.11
(which is 2272 bytes).

Can anyone tell me what is the optimum value for -s, -S and -m incase
of 802.11g based configuration?

Max


On Mon, Jul 11, 2011 at 6:57 PM, Rick Jones <rick.jones2 at hp.com> wrote:
> On 07/11/2011 03:21 AM, Max Ip wrote:
>>
>> Hi all,
>>
>> I have network connection of two laptops connected through wifi in
>> Access Point mode with bandwidth 54Mbps (802.11g).
>>
>> Now, to test the throughput, I used the following commands:
>>
>> netperf -H 192.168.1.4 -t TCP_STREAM -l 10 -c
>>
>> This gave me a TCP throughput of 11.89 Mbps.
>>
>> netperf -H 192.168.1.4 -t UDP_STREAM -l 10 -c
>>
>> This gave me a UDP throughput of 22.5 Mbps.
>>
>> I think the UDP bandwidth is ok to have 22.5 Mbps (around half of
>> 54Mbps for half duplex channel). However, how can TCP bandwidth be
>> just 11.89 Mbps?
>>
>> Could anyone help me?
>
> There can be any number of reasons.  Lost packets, flow control, small
> window size, you name it.
>
> The netperf UDP_STREAM test simply blasts data as fast as the sending stack
> will permit.  UDP does not have flow control and netperf (unless you
> ./configure --enable-intervals and set the added options) does not add any.
>  So, it will simply blast through lost traffic, unlike a TCP_STREAM test.
>  TCP will try very hard to get data to the receiver, and have it presented
> to the receiving application in order.
>
> BTW, there is no "back traffic" in a UDP_STREAM test, so unless there is
> something else communicating on your WiFi network, or other issues (eg
> losses, link-level retransmissions etc) being half-duplex shoudln't really
> matter - that or I'm clueless about WiFi (which is entirely possible :)
>
> Also, with the UDP_STREAM test, you need to consider issues of IP
> fragmentation - UDP messages larger than the MTU.  The way IP fragmentation
> and reassembly works, all the fragments must get through.  If any one
> fragment is lost, the entire datagram is effectively lost.  Thus a given
> packet loss rate is amplified as a greater message loss rate when sending
> fragmented UDP/IP datagrams.
>
> happy benchmarking,
>
> rick jones
> the attached it some generic(ish) boilerplate for you to consider.
>
> _______________________________________________
> netperf-talk mailing list
> netperf-talk at netperf.org
> http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-talk
>
>