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

[Rick Jones]

On 07/12/2011 02:36 AM, Max Ip wrote:
> Yah, thats true there should be some back traffic in UDP_STREAM test.

Well, no, actually - the UDP_STREAM test is doing just what it is 
intended to do, I just wanted to make sure it was clear to everyone what 
it was doing.

> 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).

I was just pointing-out that when one did use a value > MTU, what could 
happen to explain lower throughput.

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

That is what experimentation is all about :)

happy benchmarking,

rick jones

>
> 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
>>
>>