From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Thorsten Leemhuis <linux@leemhuis.info>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Paul Menzel <pmenzel@molgen.mpg.de>,
Ryan Hsu <ryanhsu@qti.qualcomm.com>,
"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: ath10k: Wifi slow on the XPS13 (9360) (QCA6174)
Date: Wed, 1 Nov 2017 07:25:57 +0000 [thread overview]
Message-ID: <87wp3azchn.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <94b4b903-afeb-439b-2b96-81835ab6ebef@leemhuis.info> (Thorsten Leemhuis's message of "Tue, 31 Oct 2017 16:47:18 +0100")
Thorsten Leemhuis <linux@leemhuis.info> writes:
> Lo! On 29.10.2017 08:27, Kalle Valo wrote:
>> Thorsten Leemhuis <linux@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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2017-11-01 7:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-01 8:59 ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11" Thorsten Leemhuis
2017-10-02 23:40 ` Ryan Hsu
2017-10-08 8:27 ` ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3 (Was: " Thorsten Leemhuis
2017-10-16 9:04 ` ath10k-regression due to "ath10k: fix napi_poll budget overflow" c9353bf483d3 Rouven Czerwinski
2017-10-27 9:40 ` Kalle Valo
2017-10-27 19:01 ` Ryan Hsu
2017-10-29 7:44 ` Kalle Valo
2017-10-29 10:21 ` Thorsten Leemhuis
2017-10-08 9:39 ` Wifi slow on the XPS13 (9360) (QCA6174) (Was Re: ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11") Thorsten Leemhuis
2017-10-29 7:27 ` ath10k: Wifi slow on the XPS13 (9360) (QCA6174) Kalle Valo
2017-10-31 15:47 ` Thorsten Leemhuis
2017-11-01 7:25 ` Kalle Valo [this message]
2017-10-29 7:06 ` ath10k-regression in 4.14: Connections aborts with "failed to extract amsdu: -11" Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wp3azchn.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@qca.qualcomm.com \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=pmenzel@molgen.mpg.de \
--cc=ryanhsu@qti.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox