Wireless Access

last person joined: 14 hours ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

Phy rate vs Throughput

This thread has been viewed 2 times
  • 1.  Phy rate vs Throughput

    Posted Feb 04, 2016 04:39 PM

    Hi,

    How are the phy rate of the link calculated ? .What is the relaiabilty of phy rate or instead do we need to run a throughput test ? .

    If  phy rate shows of an ac adpter shows 870 Mb , Does it mean it support 2x2 spatial streams 

    Thanks



  • 2.  RE: Phy rate vs Throughput

    EMPLOYEE
    Posted Feb 04, 2016 04:42 PM

    For a phy rate of 866, you can expect a maximum throughput of 433 Mbps. You can see spatial streams by using the command: show ap association. It varies based on channel width.



  • 3.  RE: Phy rate vs Throughput

    Posted Feb 04, 2016 06:27 PM
    Hi, When you talk about 433 Mbps , is it udp or tcp ?. Thanks


  • 4.  RE: Phy rate vs Throughput

    EMPLOYEE
    Posted Feb 04, 2016 06:29 PM
    That's maximum theoretical throughput. The protocol is irrelevant. 

    Sent from Nine


  • 5.  RE: Phy rate vs Throughput

    Posted Feb 06, 2016 03:29 AM

    Hi,

    when we  run throughput test using  iperf (tcp ) ,getting 200Mb. but when it is udp its getting around 400 Mbps

    ?

    Thank you



  • 6.  RE: Phy rate vs Throughput

    EMPLOYEE
    Posted Feb 06, 2016 06:32 AM

    TCP requires that the destination send an acknowledgement, so it has more overhead than UDP.  That holds true regardless if it is wired or wireless.



  • 7.  RE: Phy rate vs Throughput

    Posted Feb 06, 2016 12:08 PM

    Hi,

    Thank you for your reply . So when doing a throughput test , Choose UDP or TCP ?

    Thanks



  • 8.  RE: Phy rate vs Throughput

    EMPLOYEE
    Posted Feb 06, 2016 01:14 PM

    The question is, what is your goal?  TCP throughput tests one type of application and UDP tests another type.



  • 9.  RE: Phy rate vs Throughput

    Posted Feb 06, 2016 10:06 PM

    Hi,

    "For a phy rate of 866, you can expect a maximum throughput of 433 Mbps" ,

    I was asking 433 Mbps might be UDP throughput ?

    And one more question , If the  client shows phy rate 1300 Mbps , Does it mean it supports 3x3 ?

    Thanks

     

     



  • 10.  RE: Phy rate vs Throughput

    EMPLOYEE
    Posted Feb 07, 2016 07:59 AM

    Refer to this table http://mcsindex.com/

     

    So for 1300 Mbps, that is likely a 3x3 80 MHz SGI connection.



  • 11.  RE: Phy rate vs Throughput

    Posted Feb 07, 2016 09:13 AM

    Thank you all,

    I am still confused the value provided by , I could see when running iperf -u  the throughput is like 450 Mbps but when it is tcp (iperf default ) , it is 200 . So my question the value (433 Mbps by cappalli) is udp or tcp 

    Sorry for any inconvenience 

    Thank you 

     



  • 12.  RE: Phy rate vs Throughput

    EMPLOYEE
    Posted Feb 07, 2016 09:21 AM

    with iperf and tcp you can fine tune some parameters, like tcp_no_delay and tcp_window_size to get more out of it.

     

    I generally find setting tcp_no_delay and window size of 128k will give about the most you can get.

     

    You might find after setting those you can get close to that 400mbps with tcp.



  • 13.  RE: Phy rate vs Throughput

    EMPLOYEE
    Posted Feb 07, 2016 11:07 AM

    @kpaly wrote:

    Thank you all,

    I am still confused the value provided by @cappalli, I could see when running iperf -u  the throughput is like 450 Mbps but when it is tcp (iperf default ) , it is 200 . So my question the value (433 Mbps by cappalli) is udp or tcp 

    Sorry for any inconvenience 

    Thank you 

     


    The phy rate is the speed negotiated between the client and the access point.  This "rate" can go up or down based on RF conditions and protocol overhead, but it does not guarantee throughput.  It is like being on the expressway and the speed limit is 65, but because of traffic you can only go 20.  The phy rate refers to a theoretical upper limit, but only half the throughput is possible due to protocol overhead.  The speed gets even lower than that based on aggregation, RF contention and interference.

     

    The phy rate that you see a client connected at is never achievable from a throughput perspective.  There are ways to get additional throughput with iperf by changing the window size and more simultaneous streams, but it does not reflect any real world throughput testing, really.