Poor performance of Atheros QCA6174 802.11ac (rev 32) (Killer Wireless 1535)

This change was made by a bot.

Just to rule out the case of bad compatibility between the STA on the router (Quantenna QSR1000 chipset, QT3840BC SoC in case of my RT-87U) and the client WNIC I also checked with a different STA.

So the second router's 802.11ac hardware is Compex_WLE900VX Qualcomm Atheros QCA9880 (V2) which uses ath10k driver as well. Therefore, I've tested laptop's ath10k on 4.10 with router's ath10k on 4.4 kernel:

root@turris:~# uname -r
4.4.39-80079e1c1e5f9ca7ad734044462a761a-4

root@turris:~# lspci -vvv

02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 120
 Region 0: Memory at e0200000 (64-bit, non-prefetchable) [size=2M]
 Expansion ROM at e0400000 [disabled] [size=64K]
 Capabilities: [40] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit-
  Address: f1020a04 Data: 0f10
  Masking: 00fe00fe Pending: 00000000
 Capabilities: [70] Express (v2) Endpoint, MSI 00
  DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
   ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
   MaxPayload 128 bytes, MaxReadReq 512 bytes
  DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
  LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
   ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
  DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
  DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
  LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
    Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
    Compliance De-emphasis: -6dB
  LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
    EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
 Capabilities: [100 v1] Advanced Error Reporting
  UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
  UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
  UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
  CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
  CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
  AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
 Capabilities: [140 v1] Virtual Channel
  Caps: LPEVC=0 RefClk=100ns PATEntryBits...

Confirmed *NFA364xp.bin and qca61x4_2_2.bin usage by Windows. linux-firmware's version is definitely not up-to-date for this card as it refers to NFA324i (see the paste link).

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.11 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc1/

dima@blade:~$ uname -r
4.11.0-041100rc1-generic

dima@blade:~$ dpkg -l linux-firmware
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=============================================-===========================-===========================-===============================================================================================
ii linux-firmware 1.163 all Firmware for Linux kernel drivers

dima@blade:~$ journalctl -k | grep ath10k
мар 06 20:29:43 blade kernel: ath10k_pci 0000:3b:00.0: enabling device (0000 -> 0002)
мар 06 20:29:43 blade kernel: ath10k_pci 0000:3b:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
мар 06 20:29:44 blade kernel: ath10k_pci 0000:3b:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
мар 06 20:29:44 blade kernel: ath10k_pci 0000:3b:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 0 testmode 0
мар 06 20:29:44 blade kernel: ath10k_pci 0000:3b:00.0: firmware ver WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
мар 06 20:29:44 blade kernel: ath10k_pci 0000:3b:00.0: board_file api 2 bmi_id N/A crc32 6fc88fe7
мар 06 20:29:46 blade kernel: ath10k_pci 0000:3b:00.0: htt-ver 3.26 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
мар 06 20:29:46 blade kernel: ath10k_pci 0000:3b:00.0 wlp59s0: renamed from wlan0

-----------------

dima@blade:~⟫ iperf -c rtr
------------------------------------------------------------
Client connecting to rtr, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.10.10.78 port 57506 connected with 10.10.10.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 14.5 MBytes 12.1 Mbits/sec

Server-side:

RT-AC87U-F280:/tmp/home/root# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.10.10.1 port 5001 connected with 10.10.10.78 port 57506
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 14.5 MBytes 12.1 Mbits/sec

Just to confirm that ath10k changes (if any for 4.11) do not affect this: the chip firmware files are still old.

I'm also experience abysmal Wi-Fi performance with QCA6174 on a new Lenovo Yoga 910 - dropping connection every few minutes, reporting very low network strength coverage.

Out of the box, the card didn't work at all with neither Ubuntu Xenial LTS nor elementaryOS 0.4 Loki, but I got it running rudimentarily with the latest hwe-edge kernel 4.10.0.20 and linux-firmware (1.164). I've tried upgrading to the latest firmware packages from github.com /kvalo/ath10k-firmware/tree/master/QCA6174 to fix the poor connection performance of the network card, but it sadly doesn't seem to have had any noticeable effect.

I've also disabled the network card power-savings, disabled IPv6, tried all sorts of tinkering with the router, nothing seems to fix the poor performance. A weird quirk I noticed is that if the notebook is completely still, network connection drops less frequently, but if the computer is moved by just a bit, then the network connection drops noticeably.

One problem is that the network indicator doesn't even report that the connection has been lost/dropped, the only way it's noticed is the long buffering time it takes suddenly to load websites: sudo service network-manager stop/start fixes this temporarily, but this is far from a solution and very annoying.

What can I do to fix this (apart from using Windows :( )? Any recommendations?

Try to get the firmware from the linux-firmware git tree
   git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
copy the firmwares in ath10k/QCA6174/hw3.0/ to /lib/firmware/
It should help.

Thank AceLan, I gave it a try, but it seems that those files are the same or older than the ones available on github.com/kvalo/ath10k-firmware/tree/master/QCA6174 and the poor performance remains.

I also found a bug from 2015 https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1520343 , which seems related to this and affects a lot of other people - that bug was originally due to the card not being supported [which has now been fixed], but has developed lately with more comments into the random poor performance of the card under linux. Although, the original poster to this bug has provided more detailed logs for a potential solution.

I think it's apparent that there's a real problem with the linux-firmware of QCA6174 and I've personally reached a point where I'm not sure if it's worth riding it out or to jump OS-ship.

KalleValo, I added you in the hopes for some insight.

I'm having a hard time understanding this bug report, so I have some extra questions:

Is the 27.3 Mbit/s throughput transmit (laptop -> AP) or receive (AP -> laptop) speed? That's an important detail to know.

Also I see claims that this is a firmware problem, how was that conclusion made?

If receive throughput is good but transmit throughput is low when it's most like the longstanding problem ath10k has with Linux TCP stack. To confirm that there's a hack patch which workarounds the issue:

https://patchwork.kernel.org/patch/5784701/

My observations are mostly just significantly lower signal strength than another laptop I have with intel wireless during side by side test. I'm receiving an intel AC 8265 (Model 8265NGW) in the coming days to do a comparison in the same chassis for a fair test (in case of antenna performance issues).

Kalle,

The chip firmware was a guess based upon somebody else's feedback: http://lists.infradead.org/pipermail/ath10k/2016-January/006714.html

It might not be true at all and I have done some investigation after creating this bug report a month ago.

My notes from back then:

- iperf tcp vs udp performance measurements vary with QCA6174;
- iperf (2.0.5 2010) does report 200 Mbit/s on an Intel card (tcp workload);
- 200 Mbit/s is achievable on QCA6174 when generating UDP workloads via iperf;
- Upload performance (laptop -> router -> server) via rsync over ssh caps at 4 MB/s ~~ 32 Mbit/s at first. May even reach 6 MB/s ~ 48 Mbit/s or 8.5 MB at some point. But it never reaches the peak UDP rates of 200Mbit/s. This might seem ok but the fact is that stats are different for the Intel card.
- Download (server -> router -> laptop) performance with rsync caps at 62.69 MB/s (megabytes per second).
- This is not a server HDD bottleneck - the destination storage was an SSD.
- A TCP workload (iperf -c <addr>) initiated from the server side 578 Mbits/sec to iperf -s on the QCA6174 WNIC side caps at 578 Mbit/s ~ 72 MB/s

This maps well to what you are saying about the longstanding problem with ath10k & TCP stack.

I will try out the hack to confirm.

I built a Zesty test kernel with the patch posted in comment 11. The test kernel can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1670041/

Note, with this test kernel you need to install both the linux-image and linux-image-extra .deb packages.

Thanks Joseph! I will try it out.

Hi, just a quick update: I have not forgotten about trying out the new kernel. I am currently geographically far away from the access point that I used for testing and it is hard to find 802.11ac Wi-Fi in the wild.

I will provide the test results once I get to the right environment.

Tested the patched kernel - the results are consistent now across laptop -> server, server -> laptop tests for both TCP and UDP.

➜ ~ uname -a
Linux blade 4.10.0-20-generic #22~lp1670041 SMP Fri May 5 18:23:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

4 tests:
1) laptop -> server via AP (TCP);
2) laptop -> server via AP (UDP);
3) server -> laptop via AP (TCP);
4) server -> laptop via AP (UDP).

https://paste.ubuntu.com/24610258/

So with the patched kernel TCP performance seems to be fine.

Just adding that I have the same problem on a Dell XPS13 9630 with the same wifi card. Interesting though that iperf will show poor performance (10Mbit/s) but web based speedtest pages show 150Mbps. Windows will also show about 100Mbit/s with iperf running while Ubuntu will show just 10Mbit/s.

It doesn't look like the specific patch posted in #11 ever made it into mainline. Can you test the v4.12-rc4 kernel to see if the bug was fixed in a different way? It can be downloaded from:

 http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12-rc4

I'm having the same problem. Using Dell XPS13 9360. I'm a developer but doesn't know about kernel or modules. But any kind of test, I can try to help if I have some instruction how to do it.

I really like to have this problem solved.

------------

cd@cd-XPS-13-9360:~$ uname -a
Linux cd-XPS-13-9360 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

cd@cd-XPS-13-9360:~$ sudo lspci -vvv

3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
 Subsystem: Bigfoot Networks, Inc. QCA6174 802.11ac Wireless Network Adapter
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
 Latency: 0
 Interrupt: pin A routed to IRQ 135
 Region 0: Memory at dc000000 (64-bit, non-prefetchable) [size=2M]
 Capabilities: [40] Power Management version 3
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit-
  Address: fee00418 Data: 0000
  Masking: 00000000 Pending: 00000000
 Capabilities: [70] Express (v2) Endpoint, MSI 00
  DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
   ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
   MaxPayload 256 bytes, MaxReadReq 512 bytes
  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
  LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
   ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
  LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
   ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
  DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Via message
  DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
  LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
    Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
    Compliance De-emphasis: -6dB
  LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
    EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
 Capabilities: [100 v2] Advanced Error Reporting
  UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
  UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
  UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
  CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
  CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
  AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
 Capabilities: [148 v1] Virtual Channel
  Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
  Arb: Fixed- WRR32- WRR64- WRR128-
  Ctrl: ArbSelect=Fixed
  Status: InProgress...

Joseph,

No luck on 4.12.0-041200rc4-generic, unfortunately: https://paste.ubuntu.com/24826561/

Same here, #21. I have the same poor performance on 4.12-rc4.

I see the same behavior as mikewiz38: via a webtest 104 Mbps download and in the graphical interface it lists as 6Mbps.
So speed is not bad - it just looks bad (on 16.04.1 with hwe kernel 4.8.0-53)

I have the same problemi with dell XPS 13 9360.
Here the wifi info (https://github.com/UbuntuForums/wireless-info/raw/master/wireless-info) results, hope they are useful: http://paste.ubuntu.com/24848753/

@kalle valeo, your patch appears to resolve this bug, but it still exists in mainline. Do you have plans to submit this patch upstream?

I also suffer from the same bug on dell xps 13 9360, tcp wi-fi is 5-10x slower than on other devices.

@kalle we understand the patch you refer to is just a workaround, not a solution. Is anyone working on a real fix?

Dell XPS owner, I would also suggest you hassle Dell.. selling a laptop
with Ubuntu installed, where one of the devices doesn't even work properly
is a bit of a d1ck move. I've reported the issue with them which they
promised would be relayed to their hw team. More reports can't hurt!
Not that it helps but the card swap I mentioned earlier was effective
(better range, throughput and speed reporting now correct (I failed to
gather useful data for comparison before the card swap though).

On 29 Jun 2017 23:45, "Kir Kolyshkin" <email address hidden> wrote:

> I also suffer from the same bug on dell xps 13 9360, tcp wi-fi is 5-10x
> slower than on other devices.
>
> @kalle we understand the patch you refer to is just a workaround, not a
> solution. Is anyone working on a real fix?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1670041
>
> Title:
> Poor performance of Atheros QCA6174 802.11ac (rev 32) (Killer Wireless
> 1535)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/
> 1670041/+subscriptions
>

Also confirmed this bug on Dell XPS 15 (9560) with gnome ubuntu 17.04 and 4.10/4.12 kernels.

Should be the same as bug 1692836 , and there should be a fix in kernel 4.4.0-83.106

acelankao,

In 1692836 the same hack mentioned by Kalle was applied.

I am not sure it is a proper fix though as it has not landed upstream:

http://elixir.free-electrons.com/linux/latest/source/drivers/net/wireless/ath/ath10k/mac.c#L4181

skb_orphan() is not the way to go.

Can someone try the following patch ?

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 4e985dea1dd24fdecfbf9b47d51cff698e97cd2f..5f394f2f524f6ac8d8d9bef50a1bfc99397d6724 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2158,7 +2158,7 @@ static bool tcp_pacing_check(const struct sock *sk)
 }

 /* TCP Small Queues :
- * Control number of packets in qdisc/devices to two packets / or ~1 ms.
+ * Control number of packets in qdisc/devices to two packets / or ~4 ms.
  * (These limits are doubled for retransmits)
  * This allows for :
  * - better RTT estimation and ACK scheduling
@@ -2173,7 +2173,7 @@ static bool tcp_small_queue_check(struct sock *sk, const struct sk_buff *skb,
 {
        unsigned int limit;

- limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 8);
        limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
        limit <<= factor;

edumazet, i try out your path.

4.10.0-26 with path:
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.169 port 39356 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 30.9 MBytes 25.8 Mbits/sec
```

4.10.0-26 from ubuntu repo:
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.169 port 34440 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 24.8 MBytes 20.7 Mbits/sec

Thanks, can you now try :

 limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 8);

Then :

 limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 7);

Then :

 limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 7);

Yesterday something went wrong o_O

I recheck "limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 8);" to.

limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 8); (4.10.0-26)
------------------------------------------------------------
[ 3] 0.0-10.0 sec 83.6 MBytes 70.1 Mbits/sec

limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 8); (4.10.0-26)
------------------------------------------------------------
[ 3] 0.0-10.0 sec 89.6 MBytes 75.0 Mbits/sec

limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 7); (4.10.0-26)
------------------------------------------------------------
[ 3] 0.0-10.0 sec 73.8 MBytes 61.8 Mbits/sec

limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 7); (4.10.0-26)
------------------------------------------------------------
[ 3] 0.0-10.0 sec 114 MBytes 95.2 Mbits/sec

4.12.0-041200-generic
------------------------------------------------------------
[ 3] 0.0-10.0 sec 38.1 MBytes 32.0 Mbits/sec

4.10.0-26-generic
------------------------------------------------------------
[ 3] 0.0-10.0 sec 21.9 MBytes 18.3 Mbits/sec

For those who want to test it, I built a test kernel with the patch posted in comment #31. It can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1670041/

Eric,

I will try to test it on Monday as I have a pretty slow uplink where I am currently.

Hopefully, I will get back to my 5 GHz network on Thursday to do a proper comparison with the data I had before.

Thanks a lot for the feedback and suggestions - really appreciate it!

Tested with http://kernel.ubuntu.com/~jsalisbury/lp1670041/ on a 2.4 GHz network.

iperf3: interrupt - the client has terminated
➜ ~ uname -r
4.10.0-26-generic

# UDP
➜ ~ iperf3 -u -b 1000M -c <redacted>
Connecting to host <redacted>, port 5201
[ 4] local 172.29.10.20 port 37973 connected to <redacted> port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 9.69 MBytes 81.2 Mbits/sec 1240
[ 4] 1.00-2.00 sec 11.6 MBytes 97.2 Mbits/sec 1483
[ 4] 2.00-3.00 sec 11.9 MBytes 99.8 Mbits/sec 1523
[ 4] 3.00-4.00 sec 10.7 MBytes 89.4 Mbits/sec 1364
^C[ 4] 4.00-4.87 sec 10.3 MBytes 98.6 Mbits/sec 1316
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-4.87 sec 54.1 MBytes 93.1 Mbits/sec 0.000 ms 0/6926 (0%)
[ 4] Sent 6926 datagrams
iperf3: interrupt - the client has terminated

# TCP
➜ ~ iperf3 -c <redacted>
Connecting to host <redacted>, port 5201
[ 4] local 172.29.10.20 port 52878 connected to <redacted> port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 745 KBytes 6.10 Mbits/sec 0 67.9 KBytes
[ 4] 1.00-2.00 sec 659 KBytes 5.40 Mbits/sec 0 97.6 KBytes
[ 4] 2.00-3.00 sec 680 KBytes 5.57 Mbits/sec 0 129 KBytes
[ 4] 3.00-4.00 sec 659 KBytes 5.40 Mbits/sec 0 158 KBytes
[ 4] 4.00-5.00 sec 662 KBytes 5.42 Mbits/sec 0 189 KBytes
[ 4] 5.00-6.00 sec 677 KBytes 5.55 Mbits/sec 0 219 KBytes
[ 4] 6.00-7.00 sec 663 KBytes 5.43 Mbits/sec 0 250 KBytes
^C[ 4] 7.00-7.71 sec 359 KBytes 4.15 Mbits/sec 0 272 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-7.71 sec 4.99 MBytes 5.42 Mbits/sec 0 sender
[ 4] 0.00-7.71 sec 0.00 Bytes 0.00 bits/sec receiver

Will try other patches as well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041/comments/33

Eric,

Is this patch the basis for a more permanent and general fix (it seems not specific to ath10k)?

Thanks!

The patch produces a marked improvement with TCP from the local QCA6174 client to AP/remote.

4.12.0 (UDP; no patch)

% iperf3 -u -b 1000M -c remote
Connecting to host remote, port 5201
[ 4] local local port 42530 connected to remote port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 14.8 MBytes 124 Mbits/sec 10725
[ 4] 1.00-2.00 sec 17.8 MBytes 150 Mbits/sec 12924
[ 4] 2.00-3.00 sec 19.0 MBytes 160 Mbits/sec 13773
[ 4] 3.00-4.00 sec 18.1 MBytes 152 Mbits/sec 13118
[ 4] 4.00-5.00 sec 18.7 MBytes 157 Mbits/sec 13555
[ 4] 5.00-6.00 sec 18.0 MBytes 151 Mbits/sec 13064
[ 4] 6.00-7.00 sec 17.4 MBytes 146 Mbits/sec 12584
[ 4] 7.00-8.00 sec 16.8 MBytes 141 Mbits/sec 12141
[ 4] 8.00-9.00 sec 16.8 MBytes 141 Mbits/sec 12201
[ 4] 9.00-10.00 sec 17.2 MBytes 144 Mbits/sec 12442
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 175 MBytes 147 Mbits/sec 0.100 ms 0/126526 (0%)
[ 4] Sent 126526 datagrams

4.12.0 (TCP; no patch)

% iperf3 -c remote
Connecting to host remote, port 5201
[ 4] local local port 50394 connected to remote port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 2.37 MBytes 19.9 Mbits/sec 0 29.7 KBytes
[ 4] 1.00-2.00 sec 2.53 MBytes 21.2 Mbits/sec 0 29.7 KBytes
[ 4] 2.00-3.00 sec 2.43 MBytes 20.4 Mbits/sec 0 29.7 KBytes
[ 4] 3.00-4.00 sec 2.52 MBytes 21.2 Mbits/sec 0 29.7 KBytes
[ 4] 4.00-5.00 sec 2.53 MBytes 21.2 Mbits/sec 0 29.7 KBytes
[ 4] 5.00-6.00 sec 2.55 MBytes 21.4 Mbits/sec 0 29.7 KBytes
[ 4] 6.00-7.00 sec 2.55 MBytes 21.4 Mbits/sec 0 29.7 KBytes
[ 4] 7.00-8.00 sec 2.48 MBytes 20.8 Mbits/sec 0 29.7 KBytes
[ 4] 8.00-9.00 sec 2.55 MBytes 21.4 Mbits/sec 0 29.7 KBytes
[ 4] 9.00-10.00 sec 2.47 MBytes 20.7 Mbits/sec 0 29.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 25.0 MBytes 21.0 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 25.0 MBytes 20.9 Mbits/sec receiver

4.12.0 (TCP; _with_ patch)
+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 8);

% iperf3 -c remote
Connecting to host remote, port 5201
[ 4] local local port 59780 connected to remote port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 13.4 MBytes 113 Mbits/sec 0 181 KBytes
[ 4] 1.00-2.00 sec 16.9 MBytes 142 Mbits/sec 0 216 KBytes
[ 4] 2.00-3.00 sec 16.7 MBytes 140 Mbits/sec 0 252 KBytes
[ 4] 3.00-4.00 sec 17.2 MBytes 145 Mbits/sec 0 280 KBytes
[ 4] 4.00-5.00 sec 17.4 MBytes 146 Mbits/sec 0 317 KBytes
[ 4] 5.00-6.00 sec 16.9 MBytes 142 Mbits/s...

FYI, I'm using an XPS 15 9560, from this page: https://wiki.archlinux.org/index.php/Dell_XPS_13_(9360)#Wireless
It says:
"The Killer 1535 Wirless Adapter is functional and the ath10k firmware is included in recent linux kernel versions. The connection speed reported by iw is limited to 1-6Mbits/s. However this is just the output being wrong. The real connection speed is not limited to this value.
Some users are experiencing issues, where the connection is dropped under heavy load but reconnects within a brief moment. This might not be noticed during browsing at all but becomes apparent in online games. There is no know solution so far."

I noticed strange behavior.

iperf still get 20-30Mbps, but wget have 5-9MBps.

kernel 4.12 without any paths

$ wget http://cdimage.ubuntu.com/daily-live/current/artful-desktop-amd64.iso
--2017-07-12 19:17:23-- http://cdimage.ubuntu.com/daily-live/current/artful-desktop-amd64.iso
Resolving cdimage.ubuntu.com (cdimage.ubuntu.com)... 91.189.88.39
Connecting to cdimage.ubuntu.com (cdimage.ubuntu.com)|91.189.88.39|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1621032960 (1.5G) [application/x-iso9660-image]
Saving to: ‘artful-desktop-amd64.iso.1’

artful-desktop-amd64.iso.1 100%[=====================================================================>] 1.51G 8.08MB/s in 3m 33s

2017-07-12 19:20:57 (7.24 MB/s) - ‘artful-desktop-amd64.iso.1’ saved [1621032960/1621032960]

4.12 + the first change from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041/comments/33 + 802.11ac network => looks better.

➜ linux git:(6f7da290413b) ✗ git --no-pager diff
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 4858e190f6ac..abcfecfb8bbe 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2102,7 +2102,7 @@ static bool tcp_small_queue_check(struct sock *sk, const struct sk_buff *skb,
 {
  unsigned int limit;

- limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 8);
  limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
  limit <<= factor;

 uname -a
Linux blade 4.12.0-custom #1 SMP Fri Jul 14 02:49:01 MSK 2017 x86_64 x86_64 x86_64 GNU/Linux

iperf3 -c us
Connecting to host us, port 5201
[ 4] local 10.10.10.76 port 50346 connected to 10.10.10.30 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 27.2 MBytes 228 Mbits/sec 0 215 KBytes
[ 4] 1.00-2.00 sec 32.2 MBytes 270 Mbits/sec 0 298 KBytes
[ 4] 2.00-3.00 sec 31.5 MBytes 265 Mbits/sec 0 397 KBytes
[ 4] 3.00-4.00 sec 31.8 MBytes 267 Mbits/sec 0 444 KBytes
[ 4] 4.00-5.00 sec 31.5 MBytes 265 Mbits/sec 0 444 KBytes
[ 4] 5.00-6.00 sec 31.5 MBytes 264 Mbits/sec 0 444 KBytes
[ 4] 6.00-7.00 sec 31.3 MBytes 263 Mbits/sec 0 444 KBytes
[ 4] 7.00-8.00 sec 31.5 MBytes 264 Mbits/sec 0 444 KBytes
[ 4] 8.00-9.00 sec 31.3 MBytes 262 Mbits/sec 0 444 KBytes
^C[ 4] 9.00-9.94 sec 29.3 MBytes 263 Mbits/sec 0 444 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-9.94 sec 309 MBytes 261 Mbits/sec 0 sender
[ 4] 0.00-9.94 sec 0.00 Bytes 0.00 bits/sec receiver
iperf3: interrupt - the client has terminated

Eric, thank you for looking at it! I have measured all four variants that you have suggested, as well as the default ones, using linux-4.12.1 as a base.

The summary of measurements is below. Note that
 - min/max/avg is in Mbits/sec;
 - n is number of measurements, each of 1 second.

+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
min 0.00 max 39.60 avg 19.09 num 80

+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 7);
min 30.00 max 219.00 avg 174.15 num 80

+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 8);
min 0.00 max 220.00 avg 114.34 num 80

+ limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 7);
min 8.47 max 95.80 avg 68.80 num 80

+ limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 8);
min 20.20 max 169.00 avg 122.09 num 60

Despite the great discrepancy in results, it can be seen that
 - changing the values helps a lot
 - numbers 2 and 7 works the best for me.

The script to produce the output above is here:

kir@kd:~/wifiperf$ cat cal
awk '
 BEGIN {min=999999; max=n=sum=0;}
 NR==1 { print }
 $NF=="KBytes" {
  val=$7;
  if (val > max) max = val;
  if (val < min) min = val;
  sum += val;
  n = n+1;
 }
 END {
  printf("min %5.2f max %5.2f avg %5.2f num %d\n", min, max, sum/n, n)
 }'

Thanks to all of you for the tests, sorry for the delay, I have been on vacation last week.

Yes, the plan is to permanently change TCP stack, since TCP Small queue being very aggressive is no longer needed when FQ packet scheduler or BBR congestion module is used for TCP.

Kirill, would it be possible to run again your experiments, but using bbr congestion control ?

Note that you should use 4.13-rc1 so that following commit is included :
commit 218af599fa635b107cfe10acf3249c4dfe5e4123 ("tcp: internal implementation for pacing")

lpaa5:~# modprobe tcp_bbr
lpaa5:~# cat /proc/sys/net/ipv4/tcp_available_congestion_control
cubic reno bbr
lpaa5:~# cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
lpaa5:~# echo bbr >/proc/sys/net/ipv4/tcp_congestion_control
lpaa5:~# cat /proc/sys/net/ipv4/tcp_congestion_control
bbr

<run your iperf tests>

I've built a 4.13-rc1 (5771a8c08880) kernel and have done some laptop (4.13, bbr) <-> AP <-> laptop (4.4 cubic) tests. Not sure about the AP and there is a fair amount of wireless devices on the network I was connected to. Most of them have Cubic congestion control but I am not sure how fair they shared bandwidth.

There are also 2 tests with one of the public iperf3 servers from this list https://iperf.fr/iperf-servers.php which give about the same perf results. I think the network I am now has ~60 Mbit/s cap or rate limit per client.

Cwnd seems to mostly cap at 14.1 KBytes for the first set of tests.

I will run some more tests on a faster and less congested network in 2 days with bbr.

Until then, what I see is that I can get ~ 4 times more data through with UDP.

uname -r
4.13.0-rc1

➜ linux git:(5771a8c08880) ✗ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr
➜ linux git:(5771a8c08880) ✗ lsmod | grep bbr
tcp_bbr 20480 45

iperf3 -c 10.155.13.90
Connecting to host 10.155.13.90, port 5201
[ 4] local 10.155.9.186 port 37980 connected to 10.155.13.90 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 991 KBytes 8.12 Mbits/sec 1 11.3 KBytes
[ 4] 1.00-2.00 sec 938 KBytes 7.68 Mbits/sec 0 14.1 KBytes
[ 4] 2.00-3.00 sec 923 KBytes 7.56 Mbits/sec 0 11.3 KBytes
[ 4] 3.00-4.00 sec 650 KBytes 5.33 Mbits/sec 0 11.3 KBytes
[ 4] 4.00-5.00 sec 1.02 MBytes 8.56 Mbits/sec 0 11.3 KBytes
[ 4] 5.00-6.00 sec 863 KBytes 7.07 Mbits/sec 0 14.1 KBytes
[ 4] 6.00-7.00 sec 1.20 MBytes 10.1 Mbits/sec 0 14.1 KBytes
[ 4] 7.00-8.00 sec 826 KBytes 6.77 Mbits/sec 0 14.1 KBytes
[ 4] 8.00-9.00 sec 1.09 MBytes 9.12 Mbits/sec 0 11.3 KBytes
[ 4] 9.00-10.00 sec 658 KBytes 5.39 Mbits/sec 0 14.1 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 9.02 MBytes 7.57 Mbits/sec 1 sender
[ 4] 0.00-10.00 sec 8.92 MBytes 7.48 Mbits/sec receiver

iperf Done.

iperf3 -u -b 1000M -c 10.155.13.90
Connecting to host 10.155.13.90, port 5201
[ 4] local 10.155.9.186 port 44086 connected to 10.155.13.90 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 3.63 MBytes 30.5 Mbits/sec 465
[ 4] 1.00-2.00 sec 4.03 MBytes 33.8 Mbits/sec 516
[ 4] 2.00-3.00 sec 4.45 MBytes 37.3 Mbits/sec 569
[ 4] 3.00-4.00 sec 4.68 MBytes 39.3 Mbits/sec 599
[ 4] 4.00-5.00 sec 5.48 MBytes 45.9 Mbits/sec 701
[ 4] 5.00-6.00 sec 5.52 MBytes 46.3 Mbits/sec 707
[ 4] 6.00-7.00 sec 5.25 MBytes 44.0 Mbits/sec 672
[ 4] 7.00-8.00 sec 4.57 MBytes 38.3 Mbits/sec 585
[ 4] 8.00-9.00 sec 4.64 MBytes 38.9 Mbits/sec 594
[ 4] 9.00-10.00 sec 5.50 MBytes 46.1 Mbits/sec 704
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth ...

Likewise, on a non-congested network (802.11ac), directly from the laptop to the AP:

uname -r
4.13.0-rc1

➜ linux git:(5771a8c08880) ✗ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr

➜ linux git:(5771a8c08880) ✗ iperf3 -u -b 1000M -c rtr
Connecting to host rtr, port 5201
[ 4] local 10.10.10.76 port 49939 connected to rtr port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 24.6 MBytes 207 Mbits/sec 3153
[ 4] 1.00-2.00 sec 27.2 MBytes 228 Mbits/sec 3484
[ 4] 2.00-3.00 sec 26.9 MBytes 226 Mbits/sec 3441
[ 4] 3.00-4.00 sec 26.8 MBytes 225 Mbits/sec 3432
[ 4] 4.00-5.00 sec 27.0 MBytes 226 Mbits/sec 3453
[ 4] 5.00-6.00 sec 27.2 MBytes 228 Mbits/sec 3479
[ 4] 6.00-7.00 sec 26.7 MBytes 224 Mbits/sec 3421
[ 4] 7.00-8.00 sec 27.3 MBytes 229 Mbits/sec 3492
[ 4] 8.00-9.00 sec 27.2 MBytes 228 Mbits/sec 3484
[ 4] 9.00-10.00 sec 27.0 MBytes 227 Mbits/sec 3457
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 268 MBytes 225 Mbits/sec 0.035 ms 8231/34295 (24%)
[ 4] Sent 34295 datagrams

iperf Done.

➜ linux git:(5771a8c08880) ✗ iperf3 -c rtr
Connecting to host rtr, port 5201
[ 4] local 10.10.10.76 port 48172 connected to rtr port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.70 MBytes 14.2 Mbits/sec 0 11.3 KBytes
[ 4] 1.00-2.00 sec 1.59 MBytes 13.4 Mbits/sec 0 8.48 KBytes
[ 4] 2.00-3.00 sec 1.49 MBytes 12.5 Mbits/sec 0 11.3 KBytes
[ 4] 3.00-4.00 sec 1.54 MBytes 12.9 Mbits/sec 0 11.3 KBytes
[ 4] 4.00-5.00 sec 1.55 MBytes 13.0 Mbits/sec 0 8.48 KBytes
[ 4] 5.00-6.00 sec 1.50 MBytes 12.6 Mbits/sec 0 8.48 KBytes
[ 4] 6.00-7.00 sec 1.50 MBytes 12.6 Mbits/sec 0 8.48 KBytes
[ 4] 7.00-8.00 sec 1.47 MBytes 12.3 Mbits/sec 0 8.48 KBytes
[ 4] 8.00-9.00 sec 1.32 MBytes 11.1 Mbits/sec 0 8.48 KBytes
[ 4] 9.00-10.00 sec 1.43 MBytes 12.0 Mbits/sec 0 8.48 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 15.1 MBytes 12.7 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 15.0 MBytes 12.6 Mbits/sec receiver

iperf Done.

Please do not compare UDP and TCP, this is absolutely useless.

Hi Eric,

This compares Cubic with BBR with 4.13-rc2 (which has a few new commits to bbr.c):

wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000

$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
$ iperf3 -c
Connecting to host , port 5201
[ 4] local port 35242 connected to port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 2.34 MBytes 19.6 Mbits/sec 0 26.9 KBytes
[ 4] 1.00-2.00 sec 2.45 MBytes 20.6 Mbits/sec 0 26.9 KBytes
[ 4] 2.00-3.00 sec 2.36 MBytes 19.8 Mbits/sec 0 26.9 KBytes
[ 4] 3.00-4.00 sec 2.43 MBytes 20.4 Mbits/sec 0 26.9 KBytes
[ 4] 4.00-5.00 sec 2.42 MBytes 20.3 Mbits/sec 0 26.9 KBytes
[ 4] 5.00-6.00 sec 2.33 MBytes 19.5 Mbits/sec 0 29.7 KBytes
[ 4] 6.00-7.00 sec 2.48 MBytes 20.8 Mbits/sec 0 29.7 KBytes
[ 4] 7.00-8.00 sec 2.27 MBytes 19.1 Mbits/sec 0 29.7 KBytes
[ 4] 8.00-9.00 sec 2.45 MBytes 20.6 Mbits/sec 0 29.7 KBytes
[ 4] 9.00-10.00 sec 2.43 MBytes 20.4 Mbits/sec 0 29.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 24.0 MBytes 20.1 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 23.9 MBytes 20.1 Mbits/sec receiver
$ echo bbr > /proc/sys/net/ipv4/tcp_congestion_control
$ iperf3 -c
Connecting to host , port 5201
[ 4] local port 35246 connected to port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.69 MBytes 14.2 Mbits/sec 0 8.48 KBytes
[ 4] 1.00-2.00 sec 1.59 MBytes 13.4 Mbits/sec 0 8.48 KBytes
[ 4] 2.00-3.00 sec 1.43 MBytes 12.0 Mbits/sec 0 8.48 KBytes
[ 4] 3.00-4.00 sec 1.63 MBytes 13.6 Mbits/sec 0 8.48 KBytes
[ 4] 4.00-5.00 sec 1.59 MBytes 13.4 Mbits/sec 0 8.48 KBytes
[ 4] 5.00-6.00 sec 1.50 MBytes 12.6 Mbits/sec 0 8.48 KBytes
[ 4] 6.00-7.00 sec 1.59 MBytes 13.3 Mbits/sec 0 8.48 KBytes
[ 4] 7.00-8.00 sec 1.59 MBytes 13.3 Mbits/sec 0 8.48 KBytes
[ 4] 8.00-9.00 sec 1.60 MBytes 13.4 Mbits/sec 0 8.48 KBytes
[ 4] 9.00-10.00 sec 1.63 MBytes 13.6 Mbits/sec 0 8.48 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 15.8 MBytes 13.3 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 15.8 MBytes 13.2 Mbits/sec receiver

Hope that helps.

Taking a step back, the original issue for me here is that using a MacBook Air at the same location and with the same BSSID throughput (for TCP is about 100Mbits/sec). Of course it's a different phy and stack but we should be able to get much better throughput from the Atheros phy, driver and TCP stack in this scenario without very much tuning.

Patching tcp_output.c as above did make a significant difference (though not quite making up the full difference) but it looks like using BBR on the client doesn't.

Are you thinking the solution lies down the path of using BBR? Could you t...

Eric, the UDP measurement was to provide a rough estimate of what the AP is capable of sustaining without congestion control and flow control.

I did not have a different card at hand, but right now I can provide a similar measurement for comparison with the problematic card:

$ lspci | grep Wire
02:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)

$ uname -r
4.13.0-041300rc1-generic

$ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr

$ iperf3 -c rtr
Connecting to host rtr, port 5201
[ 4] local 10.10.10.208 port 33286 connected to rtr port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 8.82 MBytes 73.9 Mbits/sec 0 62.2 KBytes
[ 4] 1.00-2.00 sec 9.88 MBytes 82.9 Mbits/sec 0 56.6 KBytes
[ 4] 2.00-3.00 sec 10.2 MBytes 85.5 Mbits/sec 0 56.6 KBytes
[ 4] 3.00-4.00 sec 9.63 MBytes 80.8 Mbits/sec 0 56.6 KBytes
[ 4] 4.00-5.00 sec 10.3 MBytes 86.5 Mbits/sec 0 62.2 KBytes
[ 4] 5.00-6.00 sec 10.1 MBytes 84.4 Mbits/sec 0 62.2 KBytes
[ 4] 6.00-7.00 sec 10.0 MBytes 83.9 Mbits/sec 0 62.2 KBytes
[ 4] 7.00-8.00 sec 9.26 MBytes 77.7 Mbits/sec 0 62.2 KBytes
[ 4] 8.00-9.00 sec 10.3 MBytes 86.0 Mbits/sec 0 84.8 KBytes
[ 4] 9.00-10.00 sec 10.2 MBytes 85.5 Mbits/sec 0 70.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 98.6 MBytes 82.7 Mbits/sec 0 sender

Sorry if I was not clear, but I would like to combine #42 and #44 experiments.

Ie making sure that even with BBR on linux-4.3-rc1/rc2 (without FQ packet qdisc), we can simply tweak TCP Small queue threshold as #42 results would suggest to resolve this bug.

Thanks !

4.13-rc2 + tcp_output.c

- limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 7);

w/ cubic

% iperf3 -c dest
Connecting to host dest, port 5201
[ 4] local src port 47742 connected to dest port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 9.16 MBytes 76.8 Mbits/sec 0 218 KBytes
[ 4] 1.00-2.00 sec 10.4 MBytes 87.5 Mbits/sec 0 286 KBytes
[ 4] 2.00-3.00 sec 9.72 MBytes 81.5 Mbits/sec 0 301 KBytes
[ 4] 3.00-4.00 sec 9.95 MBytes 83.5 Mbits/sec 0 301 KBytes
[ 4] 4.00-5.00 sec 9.70 MBytes 81.3 Mbits/sec 0 301 KBytes
[ 4] 5.00-6.00 sec 9.77 MBytes 81.9 Mbits/sec 0 301 KBytes
[ 4] 6.00-7.00 sec 10.2 MBytes 85.6 Mbits/sec 0 301 KBytes
[ 4] 7.00-8.00 sec 9.92 MBytes 83.2 Mbits/sec 0 301 KBytes
[ 4] 8.00-9.00 sec 10.0 MBytes 84.0 Mbits/sec 0 345 KBytes
[ 4] 9.00-10.00 sec 10.2 MBytes 85.6 Mbits/sec 0 345 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 99.1 MBytes 83.1 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 98.5 MBytes 82.6 Mbits/sec receiver

w/ bbr

iperf3 -c dest
Connecting to host dest, port 5201
[ 4] local src port 42308 connected to dest port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 3.16 MBytes 26.5 Mbits/sec 0 11.3 KBytes
[ 4] 1.00-2.00 sec 2.58 MBytes 21.7 Mbits/sec 0 11.3 KBytes
[ 4] 2.00-3.00 sec 2.54 MBytes 21.3 Mbits/sec 0 11.3 KBytes
[ 4] 3.00-4.00 sec 2.68 MBytes 22.5 Mbits/sec 0 11.3 KBytes
[ 4] 4.00-5.00 sec 2.55 MBytes 21.4 Mbits/sec 0 11.3 KBytes
[ 4] 5.00-6.00 sec 2.53 MBytes 21.2 Mbits/sec 0 11.3 KBytes
[ 4] 6.00-7.00 sec 2.72 MBytes 22.8 Mbits/sec 0 14.1 KBytes
[ 4] 7.00-8.00 sec 2.88 MBytes 24.1 Mbits/sec 0 11.3 KBytes
[ 4] 8.00-9.00 sec 2.55 MBytes 21.4 Mbits/sec 0 11.3 KBytes
[ 4] 9.00-10.00 sec 2.86 MBytes 24.0 Mbits/sec 0 14.1 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 27.1 MBytes 22.7 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 27.0 MBytes 22.6 Mbits/sec receiver

HTH

2,8 cubic

iperf3 -c dest
Connecting to host dest, port 5201
[ 4] local src port 49522 connected to dest port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 6.17 MBytes 51.7 Mbits/sec 6 91.9 KBytes
[ 4] 1.00-2.00 sec 8.34 MBytes 70.0 Mbits/sec 7 93.3 KBytes
[ 4] 2.00-3.00 sec 8.39 MBytes 70.4 Mbits/sec 0 117 KBytes
[ 4] 3.00-4.00 sec 8.31 MBytes 69.7 Mbits/sec 6 107 KBytes
[ 4] 4.00-5.00 sec 9.83 MBytes 82.4 Mbits/sec 0 139 KBytes
[ 4] 5.00-6.00 sec 10.9 MBytes 91.6 Mbits/sec 0 168 KBytes
[ 4] 6.00-7.00 sec 11.0 MBytes 92.2 Mbits/sec 0 180 KBytes
[ 4] 7.00-8.00 sec 11.1 MBytes 92.7 Mbits/sec 0 189 KBytes
[ 4] 8.00-9.00 sec 11.1 MBytes 93.3 Mbits/sec 0 199 KBytes
[ 4] 9.00-10.00 sec 11.2 MBytes 94.2 Mbits/sec 0 206 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 96.4 MBytes 80.8 Mbits/sec 19 sender
[ 4] 0.00-10.00 sec 96.2 MBytes 80.7 Mbits/sec receiver

2,8 bbr

iperf3 -c dest
Connecting to host dest, port 5201
[ 4] local src port 49526 connected to dest port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.76 MBytes 39.9 Mbits/sec 0 14.1 KBytes
[ 4] 1.00-2.00 sec 3.77 MBytes 31.6 Mbits/sec 0 14.1 KBytes
[ 4] 2.00-3.00 sec 3.47 MBytes 29.1 Mbits/sec 0 14.1 KBytes
[ 4] 3.00-4.00 sec 2.91 MBytes 24.4 Mbits/sec 0 11.3 KBytes
[ 4] 4.00-5.00 sec 3.31 MBytes 27.7 Mbits/sec 0 14.1 KBytes
[ 4] 5.00-6.00 sec 3.25 MBytes 27.3 Mbits/sec 0 14.1 KBytes
[ 4] 6.00-7.00 sec 3.30 MBytes 27.7 Mbits/sec 0 14.1 KBytes
[ 4] 7.00-8.00 sec 3.04 MBytes 25.5 Mbits/sec 0 14.1 KBytes
[ 4] 8.00-9.00 sec 2.97 MBytes 24.9 Mbits/sec 0 11.3 KBytes
[ 4] 9.00-10.00 sec 3.44 MBytes 28.8 Mbits/sec 0 14.1 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 34.2 MBytes 28.7 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 34.0 MBytes 28.6 Mbits/sec receiver

4,7 cubic

iperf3 -c dest
Connecting to host dest, port 5201
[ 4] local src port 44612 connected to dest port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 10.7 MBytes 89.9 Mbits/sec 0 229 KBytes
[ 4] 1.00-2.00 sec 10.3 MBytes 86.1 Mbits/sec 1 205 KBytes
[ 4] 2.00-3.00 sec 11.2 MBytes 93.7 Mbits/sec 0 230 KBytes
[ 4] 3.00-4.00 sec 11.1 MBytes 93.2 Mbits/sec 0 243 KBytes
[ 4] 4.00-5.00 sec 11.3 MBytes 94.8 Mbits/sec 0 250 KBytes
[ 4] 5.00-6.00 sec 11.4 MBytes 95.7 Mbits/sec 0 255 KBytes
[ 4] 6.00-7.00 sec 11.2 MBytes 93.9 Mbits/sec 0 255 KBytes
[ 4] 7.00-8.00 sec 11.5 MBytes 96.6 Mbits/sec 0 255 KBytes
[ 4] 8.00-9.00 sec 11.2 MBytes 94.2 Mbits/sec 0 262 KBytes
[ 4] 9.00-10.00 sec 11.2 MBytes 9...

Eric,

I should have tried cubic in the previous (#46) test - quite an interesting result: http://paste.ubuntu.com/25200234/ (6 tests cubic & bbr)

lspci | grep QCA
3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)

With cubic cwnd grows quite quickly and reaches 608 KBytes in the best case while with bbr it converges to 8.48 KBytes regardless of the constants used.

I will build a 4.13rc2 kernel without any modifications and perform the same test to compare.

Disabling Powersave in NetworkManager did it for me. I was barely getting 300kB/s on certain workloads on my 2.4GHz network whereas I could get full speed on my 5GHz one. By disabling the power management in NetworkManager, I got full speed all the time and I haven't really noticed any decrease in power consumption.

Running Ubuntu 16.04.2, Kernel 4.10 (HWE branch). Stock installation done just a few minutes ago.

02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)

Doing the following will disable power saving in Network Manager by default:

$ sudo sed -i 's/wifi.powersave = 3/wifi.powersave = 2/' /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

Eric,

Once again, thanks for looking into this, and sorry for being slow. Here are the results for 4.13-rc3 kernel using BBR congestion control:

kir@kd:~/wifiperf/4.13-rc3/2$ cat results
 limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
min 7.64 max 17.30 avg 13.92 num 40
 limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 6);
min 52.20 max 95.90 avg 73.25 num 40
 limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 7);
min 17.20 max 94.80 avg 57.54 num 40
 limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 8);
min 19.00 max 80.40 avg 65.97 num 40
 limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 7);
min 53.30 max 92.50 avg 69.37 num 40
 limit = max(4 * skb->truesize, sk->sk_pacing_rate >> 8);
min 38.40 max 84.20 avg 61.54 num 40

There is not much difference in throughput (unless with default values), maybe the reason is absolute numbers are slow (my T440s wifi is about twice as fast), so there is something else involved.

Do you need to test for cubic cc?

This is with cubic:

 limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 6);
min 123.00 max 220.00 avg 194.81 num 80

and reno:

 limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 6);
min 129.00 max 224.00 avg 192.71 num 80

I suspect that iperf/iperf3 might not be a good (representative) test after all. For example, the difference with wget is not so dramatic.

4.13 without modifications:

http://paste.ubuntu.com/25499163/

scp (cubic)
➜ /tmp scp testfile srv:/tmp
testfile 8% 89MB 2.9MB/s 05:21 ETA

scp (bbr)
➜ /tmp scp testfile srv:/tmp
testfile 6% 67MB 1.7MB/s 09:09 ETA

The number from iperf3 does show big difference between Windows 10 and Linux.

Use speedtest.net to measure the speed, the gap is mainly on the upload speed.

Ubuntu w/ Linux v4.14-rc4, latest linux-firmware.git,
cubic [1]:
Ping: 5 ms
Download: 82.29 Mbps
Upload: 59.94 Mbps

bbr [2]:
Ping: 4 ms
Download: 83.51 Mbps
Upload: 54.92 Mbps

Windows 10 [3]:
Ping: 3ms
Download: 84.08 Mbps
Upload: 76.56 Mbps

[1]: http://beta.speedtest.net/result/6699920423
[2]: http://beta.speedtest.net/result/6699960328
[3]: http://beta.speedtest.net/result/6699924242

Using ubuntu 17.10, kernel 4.13-0.15-generic on XPS 13 9360 QCA6174 rev 32.
Connection on 5Ghz band AC Freebox router.

Had the same problem, however browser speedtest [1] worked fine, except that any upload on nfs or cifs were from 0 to max 1MB/s with system freeze when uploading big files.
Changed in networkmanager the MTU to 1400 (trial and error) and now the upload speed on nfs is around 25 MB/s.

Iperf still gives bad results for uploads. On NFS the speed increases from 2 MB/s - 25MB/s in about 5 seconds, so it seems that the TCP algorithm is/was the problem here.

[1] http://www.speedtest.net/my-result/6703944909
http://pic.nperf.com/r/184530901-oTbTp0X2.png

The WIFI is the bottleneck here as over Ethernet I get ~ 500mbps/200mbps.

I hope this helps.

anyone tried this from dell.com?
https://www.dell.com/support/article/uk/en/ukbsdt1/sln306440/killer-n1535-wireless-firmware-manual-update-guide-for-ubuntu-systems?lang=en

I tried that in comment #58. It's already in linux-firmware.git.

Using this guide https://www.dell.com/support/article/ng/en/ngdhs1/sln306440/killer-n1535-wireless-firmware-manual-update-guide-for-ubuntu-systems?lang=en and upgrading to latest firmware for Dell XPS 15 on Ubuntu 17.10 for the following below solved my wifi frequent connection drop while NetworkManager was still showing the Wifi was connected.

uname -r
4.13.0-16-lowlatency

dpkg -l linux-firmware | grep ii
ii linux-firmware 1.169 all Firmware for Linux kernel drivers

lspci -vvv
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
 Subsystem: Bigfoot Networks, Inc. QCA6174 802.11ac Wireless Network Adapter
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 140
 Region 0: Memory at ed200000 (64-bit, non-prefetchable) [size=2M]
 Capabilities: <access denied>
 Kernel driver in use: ath10k_pci
 Kernel modules: ath10k_pci

Hello s.illes79;

I tried to install the recommendations from Dell, I think it works for me...

uname -r
4.4.0-96-generic

 dpkg -l linux-firmware | grep ii
ii linux-firmware 1.157.13 all Firmware for Linux kernel drivers

lspci -vvv
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
 Subsystem: Dell QCA6174 802.11ac Wireless Network Adapter
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
 Latency: 0
 Interrupt: pin A routed to IRQ 282
 Region 0: Memory at d5000000 (64-bit, non-prefetchable) [size=2M]
 Capabilities: <access denied>
 Kernel driver in use: ath10k_pci
 Kernel modules: ath10k_pci

My connection was dropping every time but now looks better...

The disconnecting problem is not the same as this issue.

FWIW, I replaced the Atheros card with Intel 8265, which I bought for $20 on amazon (https://www.amazon.com/gp/product/B0721MLM8B) and haven't had any problems since. iperf results are way more stable than with Atheros. I suggest everyone to do the same thing.

There's also Intel 9260 coming up (wave 2):

https://wikidevi.com/wiki/Intel_Dual_Band_Wireless-AC_9260_(9260NGW)

Judging by this https://communities.intel.com/message/506847#506847 it's only available for OEMs as of now so maybe those will go into circulation soon for regular folks.

Meanwhile, I'll try the latest firmware from kvalo.

So, going back to question in #60, the Dell link just says to get the latest stuff from kvalo's firmware repo.

If you are on 17.10 like myself then you already have it and it doesn't help with the original problem:

➜ ~ apt policy linux-firmware
linux-firmware:
  Installed: 1.169
  Candidate: 1.169
  Version table:
 *** 1.169 500
        500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu artful/main i386 Packages
        500 http://ru.archive.ubuntu.com/ubuntu artful/main amd64 Packages
        500 http://ru.archive.ubuntu.com/ubuntu artful/main i386 Packages
        100 /var/lib/dpkg/status

➜ ~ sha256sum /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin
dc74ba148cf88f1f99a62854112ec574d8c265d88417a4d969461448b0ab60c5 /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin

➜ hw3.0 sha256sum ~/src/ath10k-firmware/QCA6174/hw3.0/firmware-4.bin_WLAN.RM.2.0-00180-QCARMSWPZ-1
dc74ba148cf88f1f99a62854112ec574d8c265d88417a4d969461448b0ab60c5 /home/username/src/ath10k-firmware/QCA6174/hw3.0/firmware-4.bin_WLAN.RM.2.0-00180-QCARMSWPZ-1

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.04 sec 29.2 MBytes 24.4 Mbits/sec 0 sender
[ 5] 0.00-10.04 sec 29.2 MBytes 24.4 Mbits/sec receiver

I encountered this issue while trying to stream from a Tobii Pro Glasses 2, i.e. ~5Mbit/sec streaming, UDP or TCP recv would freeze for 3-10 seconds once every 30 to 100 seconds. Sometimes recv would block for over 5 seconds before returning with a packet send by the host. I used a python script to compare received datarate between windows and all the linux boxes. The host is streaming ~5Mbit h264 stream, and my client is simply receiving and then discarding the packets. Windows box never reported datarate average per second beneath 600kbyte/sec, but linux would drop to 250kbyte/sec once every 30 to 100 seconds (and then jump up to 2000kbyte/sec to compensate). So it seems like it sleeping or something. Note this is UDP connection, although I also tried TCP.

I'm on a Razer Blade Stealth 2016 (Killer 1535, I.e. QCA 6174 chip). I also tried on Razer Balde 14 inch 2017 (same chip), and razer blade stealth 2015. To some extent, a Razer blade 14 inch 2015 (QCA 4000? chip?) also had the same issue.

I installed the newest firmware (as of 2 Feb), which did not solve the problem. I disabled the chip's powersaving in network manager (as suggested in #54 above by André Brait Carneiro Fabotti (andrebrait)), and this seems to have solved the issue for the most part.

I also updated to kernel 4.15 (I'm on ubuntu 17.10), which seems to have further smoothed the issue. Will report further if I encounter the problem again.

The low throughput with transmit TCP streams on ath10k should be fixed with this mac80211 commit:

mac80211: Adjust TSQ pacing shift

https://git.kernel.org/linus/36148c2bbfbe50c50206b6f61d072203c80161e0

Apparently v4.16-rc5 was the first release to have that commit.

And original commit adding the infrastructure linked to this thread ;)

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e

Then the official helper was added in

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=c9f1f58dc2eba550f208809d272bf0b14f41edba

Thanks everybody

I built a Bionic test kernel with commits 36148c2bbfbe and c9f1f58dc2eb. Commit 3a9b76fd0db9 is not needed in Bionic, since it is 3.15 based.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1670041/bionic

Can you test this kernel and see if it resolves this bug?

Joseph,

Yes, your kernel does resolve this bug. Measuring using speedtest.net, before your kernel, using the current Bionic kernel, I get 8.64mbps on a 2.4Ghz network, with a max of around 10Mbs. Four minutes later, with your kernel, 34.92Mbs with a max of around 50Mbs.

What is perhaps not so good, is that the performance of a 5Ghz network has dropped dramatically from around 90 - 100 Mbs, down to 9.12 to 9.43mbps. Tested repeatedly over a few minutes to make sure it's not just a one-off.

I'll install the stock kernel again, and check it's the patch, and not some external factor.

Yes, confirmed. It's the patch: 109.12Mbs on 5GHz with the stock kernel.

I guess the patch needs to take note of possible throughput too.

I've only looked at download speed in all these tests.

This bug was nominated against a series that is no longer supported, ie artful. The bug task representing the artful nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

I believe this issue has been fixed in newer kernel.

I have a TP-LINK TL-WDN4800 (168c:0030)，the download speed of it looks normal, but the upload speed has never been higher than 30Mbps on my ArchLinux with linux kernel 4.14 LTS. Then I switched to kernel 4.17, and iperf3 shows a 124 Mbits/sec upload bitrate.

Is there anything a Ubuntu 18.04 user (upgraded from the preinstalled Dell XPS Ubuntu 16.04) can do without manually replacing kernels and possibly compromising laptop bootability?

This is what I'm currently running:

$ uname -a
Linux dell-desktop 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

This is what iwconfig claims:

$ iwconfig
lo no wireless extensions.

wlp2s0 IEEE 802.11 ESSID:"AndroidAPCC99"
          Mode:Managed Frequency:2.422 GHz Access Point: 66:89:F1:8F:8C:99
          Bit Rate=1 Mb/s Tx-Power=20 dBm
          Retry short limit:7 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=70/70 Signal level=-24 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:51 Missed beacon:0

In practice, I get up to 20 Mb/s UL/DL when communicating with an FTP server on my phone (both my laptop and the phone support 802.11ac). Another laptop easily reaches 50 Mb/s in the same scenario.

this bug is still not solved in 20.04

Can confirm. Still present here on Ubuntu Focal, too.

I also confirm this bug on Focal.

Can confirm that this bug still exists in groovy.

I also can confirm this bug is still present in Ubuntu 20.04, speed cap at 1 Mb/s

I have this bug too.

wlp1s0 IEEE 802.11
          Mode:Managed Frequency:2.412 GHz Access Point: 54:89:98:2C:B6:05
          Bit Rate=1 Mb/s Tx-Power=20 dBm
          Retry short limit:7 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=49/70 Signal level=-61 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:19 Missed beacon:0

┌(monsterovich@dell)─(pts/0)─(~)
└─(>) wget https://speed.hetzner.de/10GB.bin
--2021-11-29 02:04:47-- https://speed.hetzner.de/10GB.bin
Распознаётся speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Подключение к speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 200 OK
Длина: 10485760000 (9,8G) [application/octet-stream]
Сохранение в каталог: ««10GB.bin»».

10GB.bin 0%[ ] 53,12M 588KB/s ост 7h 21m

The speed is incredibly low compared to external Wi-Fi adapter.

wlx000db0045477 IEEE 802.11
          Mode:Managed Frequency:2.412 GHz Access Point: 54:89:98:2C:B6:05
          Bit Rate=65 Mb/s Tx-Power=20 dBm
          Retry short long limit:2 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=70/70 Signal level=-31 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:462 Invalid misc:23 Missed beacon:0

┌(monsterovich@dell)─(pts/0)─(~)
└─(>) wget https://speed.hetzner.de/10GB.bin
--2021-11-29 02:10:01-- https://speed.hetzner.de/10GB.bin
Распознаётся speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Подключение к speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 200 OK
Длина: 10485760000 (9,8G) [application/octet-stream]
Сохранение в каталог: ««10GB.bin.2»».

10GB.bin.2 0%[ ] 23,77M 2,69MB/s ост 65m 19s

It's almost 2023. This problem still hasn't been solved. It's interesting that disabling WMM on my router magically eliminates this problem.

Linux dell 5.19.15-xanmod1 #0~20221012.git85103f7 SMP Wed Oct 12 15:04:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux