help troubleshooting low throughput

[Michal Kazior]

On 22 May 2014 11:46, Tim Harvey <tharvey at gateworks.com> wrote:
> On Thu, May 22, 2014 at 2:39 AM, Tim Harvey <tharvey at gateworks.com> wrote:
>> Greetings,
>>
>> I could use some help troubleshooting a low throughput issue. I'm
>> currently using the following:
>>  - UNEX DAXA-O1 11ac/n/a 3x3 MIMO qca988x hw2.0
>> http://www.unex.com.tw/product/daxa-o1
>>  - 80MHz channel w/o local interference
>>  - ath10k git 0dbbb028a7c461777bf4a0d53780e539e6f40e14 (May 16)
>>  - up-to-date git of hostapd/wpa_supplicant/iw
>>  - fw 10.1.467.2-1 api 2 htt 2.1
>>  - infrastructure mode using
>> http://wireless.kernel.org/en/users/Drivers/ath10k/configuration#Full_hostapd_configuration

Did you just copy&paste the example config file (and updated
interface=) or did you do something extra?

Typically the most important option is vht_capab MAX-A-MPDU-LEN-EXPx
(x=0 or 7 depending on hostapd version). Without this aggregation is
crippled and it yields pretty poor throughput.

What about the client? What is it? Is it connected in VHT80 mode?


>> I'm using iperf for throughput tests and getting no more than 220mbps
>> best case, typically more like 120mbps. The rx bitrate bounces around
>> MCS 5 to 8 and shows 3 spatial streams so I would be expecting a much
>> higher throughput. The cards are in boards with a quad-core ARM 1GHz
>> Cortex-A9 CPU and there is no indication the system is bottle-necked.
>> There are no other kernel modules loaded other thank
>> ath10k_pci/ath10k_core/ath and debugging is disabled.

Currently ath10k doesn't really scale much with number of CPUs. There
are basically two tasklets that could split the work just a little
bit, but this requires interrupt spreading. From what I know some ARM
chips can't do that so ath10k ends up using only single CPU all the
time. 1GHz of an A9 should still be enough to get you 500mbps+ though.

Did you run TCP and/or UDP tests? What direction did you test
(station->ap / ap->station)?


>> Using tcpdump/wireshark to inspect the radiotap headers I only see
>> packets with 'Antenna: 0' - Does this field indicate what transmitter
>> the pkt was received on and indicate I'm only receiving from a single
>> transmitter?

Antenna callbacks aren't implemented in master branch yet. You can
check ath-next-test for that or cherry picks Ben's patches.

You can verify max number of spatial streams with iw by looking at `HT
TX/RX MCS rate indexes supported:` and/or VHT TX/RX MCS sets.


>> I've noticed 'iw phy0 info' shows 'Available Antennas: TX 0 RX 0' and
>> any attempt to set the antenna mask with 'iw phy set antenna' fails
>> with an 'Operation not supported (-95)' - does this indicate an issue
>> with ath10k, iw, or perhaps the card's EEPROM?

It would be more helpful if you could provide `iw list` output instead
next time.


>> I've also noticed that 'iw wlan0 station dump' statistics show in the
>> rx bitrate stat that sometimes SGI is flagged and sometimes its not -
>> should I expect this to change like this? I was under the impression
>> that was a static configuration.

I think this ath10k's hw rate control is free to pick SGI/LGI
(assuming target station supports SGI at all).


[...]

> I neglected to mention that on whichever end is running the iperf
> server (receiving) I do see periodic 'failed to pop...' warnings, a
> pair of them a couple times a minute. I'm not quite clear if this is a
> hardware issue or something else:
>
> [ 3763.131280] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3769.081093] ath10k: failed to pop chained msdus, dropping
> [ 3769.086575] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3781.092383] ath10k: failed to pop chained msdus, dropping
> [ 3781.097869] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3784.367225] ath10k: failed to pop chained msdus, dropping
> [ 3784.372735] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3809.501484] ath10k: failed to pop chained msdus, dropping
> [ 3809.506993] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3821.723404] ath10k: failed to pop chained msdus, dropping
> [ 3821.728914] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3832.067136] ath10k: failed to pop chained msdus, dropping
> [ 3832.072690] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3833.632859] ath10k: failed to pop chained msdus, dropping
> [ 3833.638341] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3837.940414] ath10k: failed to pop chained msdus, dropping
> [ 3837.945982] ath10k: failed to pop amsdu from htt rx ring -22
> [ 3844.100514] ath10k: failed to pop chained msdus, dropping

You don't have to worry about these messages.

This was recently introduced by one of my patches to further analyze a
bug that Avery was seeing (kernel panic due to skb_push). I plan on
making a patch to clean this up.

Anyway, thanks for letting know :-)


Michał