Trouble shooting low rate MCS9 in 802.11ac
michal.kazior at tieto.com
Thu Aug 21 05:41:10 PDT 2014
On 21 August 2014 14:23, Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> wrote:
>>>>What do you get for UDP? That seems like pretty good TCP throughput.
>>> In VHT80 mode and rate forced to NSS3:MCS7, I can obtain 750 Mbps with
>>> less than 1% data lost (in both way, AP to STA and vice versa).
>>> Normally I can obtain 2/3 theory rate in practical (for expl NSS3:MCS3
>>> has 390 Mbps in theory, and if I force to that rate, my TCP throughput
>>> is around 270 Mbps). So I should obtain 650 Mbps in practical for TCP
>>> with NSS3:MCS7 (975 Mbps in theory). 570 Mbps is so far to 650 Mbps :(
>>Forcing the data rate isn't really optimal. Have you tried 10.2
>>firmware? I was told it has improvements in the rate control algorithm.
> Yes but it doesn't help, even worse.
> With 10.1 firmware, I can go up to 610 Mbps TCP (NSS3:MCS7 and checksum off load disabled on interface ethernet
> of the PC which connects to my station's device, I just discover it, before my rate was ~ 570 Mbps).
> With 10.2 firmware and the same config, my highest through put is only around 560 Mbps. But there is an improvement
> that the rate of MCS8 and MCS9 is not much lower than MCS7 as in 10.1 firmware. Here is a small compare between 10.1
> and 10.2 (always with NSS3)
> MCS 7: 610 vs 560 Mbps
> MCS 8: 530 vs 560 Mbps (MCS8 got the same rate as MCS7 with 10.2 firmware)
> MCS 9: 410 vs 510 Mbps
> But captured log from Wireshark still shows me VHT capab is between MCS 0-9 but VHT operation is only between MCS 0-7.
The 10.2 seems to perform slower in my cabled test environment
(~900mbps on 10.1 vs ~820mbps on 10.2) as well so far.
> And the 10.2 firmware still crashed with station on promiscuous mode. There is another bug that I also saw in 10.2 firmware,
> after a moment that my STA connected to the AP, I lost the connection (pinging non success) and this message keeps printing:
> ath10k: failed to flush transmit queue (skip 0 ar-state 1): 0
Yeah. There seems to be a bug in 10.2: 8 (that's the max I've seen so
far; never more) txed frames get stuck and are never completed by
firmware. Once you get at least 1 frame stuck you'll start getting
"failed to flush" until you stop all ath10k's interfaces.
More information about the ath10k