Running throughput tests

[Kalle Valo]

Hi Bart,

Bart Jooris <bart.jooris at gmail.com> writes:

> On 03/28/2014 04:31 PM, Kalle Valo wrote:
>
>> You are providing very little information which makes it difficult to
>> help. For starters:
>>
>> * What firmware version?
> I've cloned 'recently' https://github.com/kvalo/ath10k-firmware/
>
> tree -D /lib/firmware/ath10k/QCA988X
> └── [Mar 29 10:46] hw2.0
> ├── [Feb 26 19:39] board.bin
> ├── [Feb 26 19:39] firmware-2.bin
> └── [Feb 26 19:39] otp.bin

That doesn't tell anything about the firmware version. Please read this:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Firmware_version

You should use 10.1.467.2-1 and see this in dmesg:

[ 2651.506691] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 api 2 htt 2.1

(Please note that the info print was changed few weeks back, so it won't
look exactly same on 3.13.)

>> * What version of ath10k are you using?
>
> I compiled kernel 3.13.5.

Ok, that's a relatively old as the version of ath10k in that release is
from last October. We have had quite a few optimisations and fixes since
then but you should still easily get 400 Mbps, especially on your fast
x86 cpus.

>> * Are you sure that the host is not limiting the throughput in any way?
>>    Try to disable _all_ kernel debug options.

> /var/log/syslog and dmesg doesn't to be packed with messages related
> to the throughput test. I don't think to have seen the CPU being
> overloaded during the test.
> I'm planning to go back to the office tomorrow to verify this.
>
> Further I have these in my kernel config
> CONFIG_ATH10K=m
> CONFIG_ATH10K_PCI=m
> # CONFIG_ATH10K_DEBUG is not set
> CONFIG_ATH10K_DEBUGFS=y
> CONFIG_ATH10K_TRACING=y
>
> I will disable the last two too.

Ok, this looks good. But just to confirm, can you send the full kernel
config file as well?

>> * Also describe your test setup in detail.
>>
> Common for AP and STA:
>
> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
> -Kernel 3.13.5 containing the ath10k modules
> -firmwares cloned end of February
> -iperf in udp mode used for the  throughput test
>
> AP only:
> -ubuntu 12.04 LTS as crda wouldn't build on ubuntu 13.10 (libgcrypt issue).
> -hostapd v2.2-devel
> -modified regulatory database and crda build
> -your Full_hostapd_configuration + channel=36 and vht_oper_centr_freq_seg0_idx=42
>
> STA only:
> -ubuntu 13.10
> -nmcli is used to connect to the AP
>
> Distance between AP and STA: 60 cm. Antenna's are now directed
> orthogonal per device, antennaX (X=1..3) on both devices are pointing
> in the same direction. Although I've played a lot with the antenna's
> directions already and I can't remember one run where it had a lot of
> impact...
>
> The spectrum analyser measured a band of almost 80MHz being used.

This looks good as well. Is it possible for you take debug logs? First
enable these ath10k options:

CONFIG_ATH10K_DEBUG=y
CONFIG_ATH10K_DEBUGFS=y
CONFIG_ATH10K_TRACING=y

And start ath10k with debug mask 0x432, which prints info related to
firmware configuration:

modprobe ath10k_core.ko debug_mask=0x432

Also start hostapd with -dddt and connect the ath10k STA to the AP. Then
send here both the full dmesg output, preferably starting from kernel
boot, and hostapd debug logs here from the AP. No need to run any
throughput tests in this case, I just want to see how we configure the
firmware when the STA associates.

And even better if you could use trace-cmd, we get more logs that way:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Tracing

-- 
Kalle Valo