ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

[Kalle Valo]

Thorsten Leemhuis <linux at leemhuis.info> writes:

> Lo! On 29.10.2017 08:27, Kalle Valo wrote:
>> Thorsten Leemhuis <linux at leemhuis.info> writes:
>>> On 03.10.2017 01:40, Ryan Hsu wrote:
>>>> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
>>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>>> ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
>>>>>> ath10k_pci 0000:3a:00.0: Direct firmware load for
>>>>>> ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
>>>>> Do they have anything to do with this? Hardware is
>>>> This error message is confusing since QCA6174 is not supporting
>>>> pre-calibration feature, this reminds me that we need to clean this up.
>>> I guess that would be good to avoid confusion. But while at it: If you
>>> have a minute, could you please explain to me how to properly set up the
>>> wifi firmware files for my Dell XPS13 (9360)? The reasons why I'm
>>> asking: Sending data via wifi is really slow on my laptop (scp copies
>>> only get 2 to 5 MByte/s on networks that are known to be a lot faster).
>>> I wonder if the firmware files or the calibration data is part of the
>>> reason wifi Tx is slow. The machine is normally shipped with a slightly
>>> enhanced Ubuntu 16.04. That among others contains a package with the
>>> machine specific files board.bin and board-2.bin that replace the files
>>> normally installed in /lib/firmware/ath10k/QCA6174/hw3.0/ Are those
>>> machine specific files crucial to have or are the one from the
>>> linux-firmware repo good enoguh? I'm using Fedora and could copy the
>>> ones from Ubuntu over, but obviously they will get overwritten every
>>> time Fedora ships a new linux-firmware package – IOW: every few weeks :-/
>> Yes, the board file can affect throughtput, _both_ TCP and UDP. I don't
>> know what board files Ubuntu is shipping but we should try to get those
>> into upstream.
>
> Out of curiosity (don't spend time answering this is you are busy): Is
> there even a mechanism for this? Kind of "take
> firmwaredir/board-Dell_Inc.-XPS_13_9360.bin if it exists and
> firmwaredir/board.bin otherwise? Or can one file serve all machines?

Just to a quick short answer:

board.bin contains just one board file but board-2.bin is in practise a
container format which has multiple board files (or "images"). Each
image has a name associated to it which ath10k uses to find the correct
image. Example:

bus=pci,vendor=168c,device=003e,subsystem-vendor=144d,subsystem-device=c14f,variant=K

So yes, we have infrastructure ready to provide multiple board files.
But usually the challenge is how to make ath10k correctly detect what
board file a particular system needs.

>>> Side note: You find a lot of reports about slow wifi is you search the
>>> net with terms like "9360 wifi slow linux". Ubuntu fixed that a few
>>> months ago with this patch:
>>> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=9690f19f07fee2acb2b04ea5eaa5db184ee175d5
>>> Some bugs about this:
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1692836
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041
>> But this again about interraction between ath10k and TCP stack. And it
>> _only_ affects TCP, UDP should be unaffected.
>
> Ahh, sorry, missed that. Seems I didn't properly read the second
> launchpad link above. Sorry.
>
>> So whenever testing
>> throughput please always measure both TCP and UDP because then it's
>> easier to pinpoint the reason.
>
> Is there any data I could provide that might help getting this soled
> once and for all?

With "this" you mean TCP transmit throughput problem with ath10k? I
don't think there's any easy solution, we just need to start a serious
discussion with the TCP maintainers how to solve this. IIRC ath10k
didn't have this problem until something changed in the TCP stack, so in
theory this could be classified as a regression in the TCP stack. But
I'm not sure about that and need to check the history.

But what would be helpful to have a detailed summary of the issue,
pointers to past discussions and identify the TCP commit which started
all this etc. I'll try to do that before the Netdev 2.2 but let's see if
I can make it. Help with that is really welcome.

-- 
Kalle Valo