You are not logged in.
Dear Sir,
I test throughput with 54 Mbps PHY rate. When I test throughput, I just let STA keep transmitting packet(1500 bytes) to AP,and calculate the throughput at AP.
The result is the same as the throughput graph on the Warp web(actual speed will achieve about 29 Mbps).
Then I did iperf test, I configured an AP and connected its ETHA with a PC , a STA connected with another PC at the same way.
Send packet from PC which connected with STA to which connected with AP.
The result is about 24.7 Mbps.
I would like to know what's different between these two situation?
I guess that when I test iperf , there is more code which CPU need to process and extra ethernet interrupt should be handled.
But I'm not really sure whether I am right.
Is there any other reason cause tihs difference?
Thanks
Last edited by FeilxTang (2017-Nov-16 05:17:40)
Offline
Is the iperf test using UDP or TCP? A backlogged UDP test should be the closest to approximation of a backlogged LTG. If you are using UDP, making sure that you are requesting iperf test bandwidth larger than 30Mbps, and still observing a lower-than-expected throughput, then the next step is to try to figure out where the losses are coming from.
The first place I'd look is the transmit queue to make sure that it is being kept filled by the Ethernet receptions. If the queue ever empties in the middle of the experiment, that means that the DCF is being starved of packets to send for some reason. To check on the status of the Tx queue, the best way is to use wlan_exp over ETH_B in conjunction with using iperf over ETH_A. If you pull the logs from your transmitting node after the iperf experiment, you can take a look at the "queue_occupancy" field in the TX_HIGH log entries. This field will tell you what the occupancy of the queue was immediately after the packet corresponding to that entry was enqueued. If that value ever drops to 1 during the the iperf experiment it could help explain why the throughput was lower than you expected -- there wasn't a packet ready to send when the DCF wanted to send the next packet.
Another thing to verify is that iperf is sending full MTU payloads. You could run wireshark on the PC running wireshark to verify that it's packets are full size. If iperf is sending small packets, that could also explain the drop in throughput.
Offline