Report for: Wifi Capacity Test

PDF Report

Objective

The Candela WiFi Capacity test is designed to measure performance of an Access Point when handling different amounts of WiFi Stations. The test allows the user to increase the number of stations in user defined steps for each test iteration and measure the per station and the overall throughput for each trial. Along with throughput other measurements made are client connection times, Fairness, % packet loss, DHCP times and more. The expected behavior is for the AP to be able to handle several stations (within the limitations of the AP specs) and make sure all stations get a fair amount of airtime both in the upstream and downstream. An AP that scales well will not show a significant over-all throughput decrease as more stations are added.

Realtime Graph shows summary download and upload RX bps of connections created by this test.
Realtime BPS

Total bits-per-second transferred. This only counts the protocol payload, so it will not count the Ethernet, IP, UDP, TCP or other header overhead. A well behaving system will show about the same rate as stations increase. If the rate decreases significantly as stations increase, then it is not scaling well.
If selected, the Golden AP comparison graphs will be added. These tests were done in an isolation chamber, open encryption, conductive connection, with LANforge CT525 wave-1 3x3 NIC as the stations.
Total Kbps Received vs Number of Stations Active

Total Kbps Received vs Number of Stations Active

Text Data for Kbps Upload/Download

Protocol-Data-Units received. For TCP, this does not mean much, but for UDP connections, this correlates to packet size. If the PDU size is larger than what fits into a single frame, then the network stack will segment it accordingly. A well behaving system will show about the same rate as stations increase. If the rate decreases significantly as stations increase, then it is not scaling well.
Total PDU/s Received vs Number of Stations Active

Total PDU/s Received vs Number of Stations Active

Text Data for Pps Upload/Download

Station disconnect stats. These will be only for the last iteration. If the 'Clear Reset Counters' option is selected, the stats are cleared after the initial association. Any re-connects reported indicate a potential stability issue. Can be used for long-term stability testing in cases where you bring up all stations in one iteration and then run the test for a longer duration.
Port Reset Totals

Station connect time is calculated from the initial Authenticate message through the completion of Open or RSN association/authentication.
Station Connect Times

This measures the time it takes to complete the ANQP communication. This is used in Hot-Spot 2.0 (HS20) negotiation and discovery.
Station ANQP Times

This measures the time it takes to complete the 4-way Authentication used by WPA encryption. If this increases as more stations are added, it may indicate scalability problems.
Station 4-Way Auth Times

This measures the time it takes to acquire a DHCP lease. The DHCP protocol broadcasts at least one discovery message and then waits a second or two before trying to aquire a lease. So, longer times here are usually not a problem. If the time goes up as more stations associate then it may indicate scalability issues, and it may also mean that the DHCP server has run out of leases.
Station DHCP Times

This measures the one-way latency reported by LANforge. Much of the latency will be in the LANforge itself when transmitting at maximum speeds because LANforge will have fairly large send buffers. You can force the send buffers smaller to decrease this. But, the device-under-test can also influence over-all latency. We often see multiple seconds of latency in our testing, but in a perfect world you would want the latency to not increase much as more stations are added.
Latency vs Time

This packet loss is calculated based on the sequence-gap detected drops. If the device-under-test is reordering packets, then this value may be incorrect. Check the Layer-3 Endpoint out-of-order column if this graph is significantly different from the cx-detected-drop graph above.
Total Drop % vs Number of Stations Active (Sequence Gap Detected Drops)

Total Drop % vs Number of Stations Active (Sequence Gap Detected Drops)

This packet loss is calculated based on the number of PDUs sent by one side versus the number received on the other. Please note that TCP does not actually drop packets, but it will instead just run slower and retransmit frames. UDP will give more accurate packet-loss statistics.
Total Drop % vs Number of Stations Active (Send vs Receive Detected Drops)

Total Drop % vs Number of Stations Active (Send vs Receive Detected Drops)

Text Data for CX Drop Percent Upload/Download

This charts the total time it takes the stations to associate and acquire a DHCP lease (if DHCP is being used). If the system is scaling well, this time should not increase much as more stations are brought up.
Stations requested UP vs Bringup Time for Last Batch of 228 Stations

Stations requested UP vs Bringup Time for Last Batch of 228 Stations

Wifi-Capacity Test requested values
Station Increment:	1,2,5,10,20,45,60,100
Loop Iterations:	Single (1)
Duration:	1 min (1 m)
Protocol:	TCP-IPv4
Layer 4-7 Endpoint:	NONE
Payload Size:	AUTO
MSS	AUTO
Total Download Rate:	1G (1 Gbps)
Total Upload Rate:	1G (1 Gbps)
Percentage TCP Rate:	10% (10%)
Set Bursty Minimum Speed:	Burst Mode Disabled (-1)
Randomize Rates	true
Leave Ports Up	false
Socket buffer size:	OS Default
Settle Time:	5 sec (5 s)
Rpt Timer:	fast (1 s)
IP ToS:	Best Effort (0)
Multi-Conn:	AUTO
Show-Per-Iteration-Charts	true
Show-Per-Loop-Totals	true
Hunt-Lower-Rates	false
Show Events	true
Clear Reset Counters	false
CSV Reporting Dir	- not selected -
Build Date	Sat May 2 10:22:39 PDT 2020
Build Version	5.4.2
Git Version	1c7aa80894052fe3b618e8f17ba7de8b47bafc45
Ports	1.1.eth0 1.1.sta00000 1.1.sta00001 1.1.sta00002 1.1.sta00003 1.1.sta00004 1.1.sta00005 1.1.sta00006 1.1.sta00007 1.1.sta00008 1.1.sta00009 1.1.sta00010 1.1.sta00011 1.1.sta00012 1.1.sta00013 1.1.sta00014 1.1.sta00015 1.1.sta00016 1.1.sta00017 1.1.sta00018 1.1.sta00019 1.1.sta00020 1.1.sta00021 1.1.sta00022 1.1.sta00023 1.1.sta00024 1.1.sta00025 1.1.sta00026 1.1.sta00027 1.1.sta00028 1.1.sta00029 1.1.sta00030 1.1.sta00031 1.1.sta00032 1.1.sta00033 1.1.sta00034 1.1.sta00035 1.1.sta00036 1.1.sta00037 1.1.sta00038 1.1.sta00039 1.1.sta00040 1.1.sta00041 1.1.sta00042 1.1.sta00043 1.1.sta00044 1.1.sta00045 1.1.sta00046 1.1.sta00047 1.1.sta00048 1.1.sta00049 1.1.sta00050 1.1.sta00051 1.1.sta00052 1.1.sta00053 1.1.sta00054 1.1.sta00055 1.1.sta00056 1.1.sta00057 1.1.sta00058 1.1.sta00059 1.1.sta00060 1.1.sta00061 1.1.sta00062 1.1.sta00063 1.1.sta00500 1.1.sta00501 1.1.sta00502 1.1.sta00503 1.1.sta00504 1.1.sta00505 1.1.sta00506 1.1.sta00507 1.1.sta00508 1.1.sta00509 1.1.sta00510 1.1.sta00511 1.1.sta00512 1.1.sta00513 1.1.sta00514 1.1.sta00515 1.1.sta00516 1.1.sta00517 1.1.sta00518 1.1.sta00519 1.1.sta00520 1.1.sta00521 1.1.sta00522 1.1.sta00523 1.1.sta00524 1.1.sta00525 1.1.sta00526 1.1.sta00527 1.1.sta00528 1.1.sta00529 1.1.sta00530 1.1.sta00531 1.1.sta00532 1.1.sta00533 1.1.sta00534 1.1.sta00535 1.1.sta00536 1.1.sta00537 1.1.sta00538 1.1.sta00539 1.1.sta00540 1.1.sta00541 1.1.sta00542 1.1.sta00543 1.1.sta00544 1.1.sta00545 1.1.sta00546 1.1.sta00547 1.1.sta00548 1.1.sta00549 1.1.sta00550 1.1.sta00551 1.1.sta00552 1.1.sta00553 1.1.sta00554 1.1.sta00555 1.1.sta00556 1.1.sta00557 1.1.sta00558 1.1.sta00559 1.1.sta00560 1.1.sta00561 1.1.sta00562 1.1.sta00563 1.1.sta00564 1.1.sta00565 1.1.sta00566 1.1.sta00567 1.1.sta00568 1.1.sta00569 1.1.sta00570 1.1.sta00571 1.1.sta00572 1.1.sta00573 1.1.sta00574 1.1.sta00575 1.1.sta00576 1.1.sta00577 1.1.sta00578 1.1.sta00579 1.1.sta00580 1.1.sta00581 1.1.sta00582 1.1.sta00583 1.1.sta00584 1.1.sta00585 1.1.sta00586 1.1.sta00587 1.1.sta00588 1.1.sta00589 1.1.sta00590 1.1.sta00591 1.1.sta00592 1.1.sta00593 1.1.sta00594 1.1.sta00595 1.1.sta00596 1.1.sta00597 1.1.sta00598 1.1.sta00599 1.1.sta01000 1.1.sta01001 1.1.sta01002 1.1.sta01003 1.1.sta01004 1.1.sta01005 1.1.sta01006 1.1.sta01007 1.1.sta01008 1.1.sta01009 1.1.sta01010 1.1.sta01011 1.1.sta01012 1.1.sta01013 1.1.sta01014 1.1.sta01015 1.1.sta01016 1.1.sta01017 1.1.sta01018 1.1.sta01019 1.1.sta01020 1.1.sta01021 1.1.sta01022 1.1.sta01023 1.1.sta01024 1.1.sta01025 1.1.sta01026 1.1.sta01027 1.1.sta01028 1.1.sta01029 1.1.sta01030 1.1.sta01031 1.1.sta01032 1.1.sta01033 1.1.sta01034 1.1.sta01035 1.1.sta01036 1.1.sta01037 1.1.sta01038 1.1.sta01039 1.1.sta01040 1.1.sta01041 1.1.sta01042 1.1.sta01043 1.1.sta01044 1.1.sta01045 1.1.sta01046 1.1.sta01047 1.1.sta01048 1.1.sta01049 1.1.sta01050 1.1.sta01051 1.1.sta01052 1.1.sta01053 1.1.sta01054 1.1.sta01055 1.1.sta01056 1.1.sta01057 1.1.sta01058 1.1.sta01059 1.1.sta01060 1.1.sta01061 1.1.sta01062 1.1.sta01063
Firmware	N/A 10.1-ct-8x-__xtH-022-db8cfc6c 0.3-0
Machines	ben-ota-2


Requested Parameters:
Download Rate: Per station: 1000000000 (   1 Gbps)  All:   1000000000 (   1 Gbps)
Upload Rate:   Per station: 1000000000 (   1 Gbps)  All:   1000000000 (   1 Gbps)
                                                 Total:    2000000000 (   2 Gbps)
Station count: 1   Connections per station: 1   Payload (PDU) sizes: AUTO (AUTO)

Observed Rate:
Download Rate:     Cx Min: 332.757 Mbps  Cx Ave: 332.757 Mbps  Cx Max: 332.757 Mbps  All Cx: 332.757 Mbps
Upload Rate:       Cx Min: 200.008 Mbps  Cx Ave: 200.008 Mbps  Cx Max: 200.008 Mbps  All Cx: 200.008 Mbps
                                                                                     Total: 532.766 Mbps
Aggregated Rate:   Min:    532.766 Mbps  Avg:    532.766 Mbps  Max:    532.766 Mbps

This graph shows fairness.  On a fair system, each station should get about the same throughput.
In the download direction, it is mostly the device-under-test that is responsible for this behavior,
but in the upload direction, LANforge itself would be the source of most fairness issues
unless the device-under-test takes specific actions to ensure fairness.

Report for: Wifi Capacity Test

Sat May 02 14:47:49 PDT 2020

Objective