Dell XPS 9360 wifi 5G performance is poor

[AceLan Kao]

TX throughput is not good in Ubuntu in IEEE 802.11ac mode.

Measured Rx 60Mbit/s and Tx 12Mbit/s with Ubuntu
Windows 10 (1607) performs much better with on transmit side Rx 73MBit/s and Tx 62MBit/s using the same hardware setup.
Same result with WPA2 disabled in unencrypted mode.

Steps to Reproduce:
1. connect to Wifi
2. copy a large file from XPS 13 to a share on a 2nd system

[AceLan Kao (acelankao)]

This patch seems to fix the issue on Ubuntu 4.4 kernel.
The ath10k driver structure has been changed after 4.4, so this fix can't apply to 4.8+ kernel,
and it looks like should stay in 4.4 kernel only.

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3563,6 +3563,8 @@ static void ath10k_tx(struct ieee80211_hw *hw,
      struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
      __le16 fc = hdr->frame_control;

+ skb_orphan(skb);
+
      /* We should disable CCK RATE due to P2P */
      if (info->flags & IEEE80211_TX_CTL_NO_CCK_RATE)

[AceLan Kao (acelankao)]

Test result without patch on comment #1:
11n:
------------------------------------------------------------
Client connecting to 192.168.158.106, TCP port 5001
TCP window size: 416 KByte (WARNING: requested 100 MByte)
------------------------------------------------------------
[ 3] local 192.168.158.107 port 36578 connected with 192.168.158.106 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 24.0 MBytes 20.1 Mbits/sec
[ 3] 10.0-20.0 sec 23.5 MBytes 19.7 Mbits/sec
[ 3] 20.0-30.0 sec 23.8 MBytes 19.9 Mbits/sec
[ 3] 30.0-40.0 sec 22.9 MBytes 19.2 Mbits/sec
[ 3] 40.0-50.0 sec 24.1 MBytes 20.2 Mbits/sec
[ 3] 50.0-60.0 sec 24.0 MBytes 20.1 Mbits/sec
[ 3] 60.0-70.0 sec 19.2 MBytes 16.1 Mbits/sec
[ 3] 70.0-80.0 sec 16.0 MBytes 13.4 Mbits/sec
[ 3] 80.0-90.0 sec 23.8 MBytes 19.9 Mbits/sec
[ 3] 90.0-100.0 sec 23.2 MBytes 19.5 Mbits/sec
[ 3] 100.0-110.0 sec 23.1 MBytes 19.4 Mbits/sec
[ 3] 110.0-120.0 sec 23.4 MBytes 19.6 Mbits/sec
[ 3] 0.0-120.1 sec 271 MBytes 18.9 Mbits/sec

11AC:
------------------------------------------------------------
Client connecting to 192.168.158.106, TCP port 5001
TCP window size: 416 KByte (WARNING: requested 100 MByte)
------------------------------------------------------------
[ 3] local 192.168.158.107 port 36594 connected with 192.168.158.106 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 12.0 MBytes 10.1 Mbits/sec
[ 3] 10.0-20.0 sec 12.1 MBytes 10.2 Mbits/sec
[ 3] 20.0-30.0 sec 12.6 MBytes 10.6 Mbits/sec
[ 3] 30.0-40.0 sec 12.8 MBytes 10.7 Mbits/sec
[ 3] 40.0-50.0 sec 9.12 MBytes 7.65 Mbits/sec
[ 3] 50.0-60.0 sec 11.8 MBytes 9.86 Mbits/sec
[ 3] 60.0-70.0 sec 12.2 MBytes 10.3 Mbits/sec
[ 3] 70.0-80.0 sec 11.1 MBytes 9.33 Mbits/sec
[ 3] 80.0-90.0 sec 11.8 MBytes 9.86 Mbits/sec
[ 3] 90.0-100.0 sec 11.5 MBytes 9.65 Mbits/sec
[ 3] 100.0-110.0 sec 11.6 MBytes 9.75 Mbits/sec
[ 3] 110.0-120.0 sec 12.5 MBytes 10.5 Mbits/sec
[ 3] 0.0-120.2 sec 141 MBytes 9.86 Mbits/sec

Test result with the patch on comment #1:
11n:
------------------------------------------------------------
Client connecting to 192.168.158.106, TCP port 5001
TCP window size: 416 KByte (WARNING: requested 100 MByte)
------------------------------------------------------------
[ 3] local 192.168.158.107 port 57252 connected with 192.168.158.106 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 172 MBytes 144 Mbits/sec
[ 3] 10.0-20.0 sec 184 MBytes 154 Mbits/sec
[ 3] 20.0-30.0 sec 100 MBytes 84.3 Mbits/sec
[ 3] 30.0-40.0 sec 172 MBytes 144 Mbits/sec
[ 3] 40.0-50.0 sec 187 MBytes 157 Mbits/sec
[ 3] 50.0-60.0 sec 180 MBytes 151 Mbits/sec
[ 3] 60.0-70.0 sec 177 MBytes 148 Mbits/sec
[ 3] 70.0-80.0 sec 190 MBytes 159 Mbits/sec
[ 3] 80.0-90.0 sec 179 MBytes 150 Mbits/sec
[ 3] 90.0-100.0 sec 183 MBytes 153 Mbits/sec
[ 3] 100.0-110.0 sec 180 MBytes 151 Mbits/sec
[ 3] 110.0-120.0 sec 185 MBytes 155 Mbits/sec
[ 3] 0.0-120.0 sec 2.04 GBytes 146 Mbits/sec

11AC:
------------------------------------------------------------
Client connecting to 192.168.158.106, TCP port 5001
TCP window size: 416 KByte (WARNING: requested 100 MByte)
------------------------------------------------------------
[ 3] local 192.168.158.107 port 57236 connect...

[AceLan Kao (acelankao)]

This patch has been submitted

[Mario Limonciello (superm1)]

Yes it looks like it was refactored as a result of f2f6ecabe, but following the refactor here is where it would go in a newer kernel.

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 3029f25..8441b33 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4138,6 +4138,8 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
        bool is_presp;
        int ret;

+ skb_orphan(skb);
+
        ath10k_mac_tx_h_fill_cb(ar, vif, txq, skb);

        txmode = ath10k_mac_tx_h_get_txmode(ar, vif, sta, skb);

Can you please check if on 4.11 the problem exists and that still fixes it in 4.11? If so, it makes sense to me to try to submit upstream this fix.

[AceLan Kao (acelankao)]

Hi Mario,

Do you know who is the author of this patch? Why he doesn't submit it? And are there any drawbacks by calling that function?

I could SRU the patch to Ubuntu kernel(4.8/4.10), but it's a little bit risky to submit it to upstream if I don't understand the patch well.

To setup the test environment takes time, I can try verifying it next week(we are on holiday next Monday and Tuesday).

[Mario Limonciello (superm1)]

@acelan,
I'm unsure on where this patch first came from and also don't understand the impact from calling this. I know it was discussed on some forums as a solution to performance problems. The reason that the vendor hasn't submitted upstream is they said there was discussion that this should be fixed in TCP driver and it's cross vendor impact. I don't think that is true because this is not seen on Intel, only on QCA.

Given that and assuming it still has the large performance improvement on newer kernel I think it's worth an attempt to submit upstream along with the test data. The data is irrefutable and if the maintainers think it would be better to put the patch somewhere else, they can recommend where it should go.

[Kleber Sacilotto de Souza (kleber-souza)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Po-Hsu Lin (cypressyew)]

Verified with 201606-22355 Dell XPS 13 9360
The fix in -proposed make significant improvement for the performance.

Before -proposed:

== AC ==
sftp put ubuntu-17.04-desktop-amd64.iso (1535MB) 1.1MB/s 23:45
iperf speed test: 0.0-120.1 sec 140 MBytes 9.81 Mbits/sec

== N ==
iperf speed test: 0.0-120.1 sec 212 MBytes 14.8 Mbits/sec

---- After install the -proposed kernel:

== AC ==
sftp put ubuntu-17.04-desktop-amd64.iso (1535MB) 6.7MB/s 03:50
iperf speed test: 0.0-120.0 sec 737 MBytes 51.5 Mbits/sec

== N ==
iperf speed test
iperf speed test: 0.0-120.0 sec 1.06 GBytes 75.7 Mbits/sec

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.4.0-83.106

---------------
linux (4.4.0-83.106) xenial; urgency=low

  * linux: 4.4.0-83.106 -proposed tracker (LP: #1700541)

  * CVE-2017-1000364
    - Revert "UBUNTU: SAUCE: mm: Only expand stack if guard area is hit"
    - Revert "mm: do not collapse stack gap into THP"
    - Revert "mm: enlarge stack guard gap"
    - mm: vma_adjust: remove superfluous confusing update in remove_next == 1 case
    - mm: larger stack guard gap, between vmas
    - mm: fix new crash in unmapped_area_topdown()
    - Allow stack to grow up to address space limit

linux (4.4.0-82.105) xenial; urgency=low

  * linux: 4.4.0-82.105 -proposed tracker (LP: #1699064)

  * CVE-2017-1000364
    - SAUCE: mm: Only expand stack if guard area is hit

  * linux-aws/linux-gke incorrectly producing and using linux-*-tools-
    common/linux-*-cloud-tools-common (LP: #1688579)
    - [Config] make linux-tools-common and linux-cloud-tools-common protection
      consistent

  * CVE-2017-9242
    - ipv6: fix out of bound writes in __ip6_append_data()

  * CVE-2017-9075
    - sctp: do not inherit ipv6_{mc|ac|fl}_list from parent

  * CVE-2017-9074
    - ipv6: Prevent overrun when parsing v6 header options

  * CVE-2017-9076
    - ipv6/dccp: do not inherit ipv6_mc_list from parent

  * CVE-2017-9077
    - ipv6/dccp: do not inherit ipv6_mc_list from parent

  * CVE-2017-8890
    - dccp/tcp: do not inherit mc_list from parent

  * Module signing exclusion for staging drivers does not work properly
    (LP: #1690908)
    - SAUCE: Fix module signing exclusion in package builds

  * extend-diff-ignore should use exact matches (LP: #1693504)
    - [Packaging] exact extend-diff-ignore matches

  * Dell XPS 9360 wifi 5G performance is poor (LP: #1692836)
    - SAUCE: ath10k: fix the wifi speed issue for kill 1535

  * Upgrade Redpine WLAN/BT driver to ver. 1.2.RC12 (LP: #1694607)
    - SAUCE: Redpine: Upgrade to ver. 1.2.RC12

  * [DP MST] No audio output through HDMI/DP/mDP ports in Dell WD15 and TB15
    docking stations (LP: #1694665)
    - drm/i915: Store port enum in intel_encoder
    - drm/i915: Eliminate redundant local variable definition
    - drm/i915: Switch to using port stored in intel_encoder
    - drm/i915: Move audio_connector to intel_encoder
    - drm/i915/dp: DP audio API changes for MST
    - drm/i915: abstract ddi being audio enabled
    - drm/i915/audio: extend get_saved_enc() to support more scenarios
    - drm/i915: enable dp mst audio

  * Xenial update to 4.4.70 stable release (LP: #1694621)
    - usb: misc: legousbtower: Fix buffers on stack
    - usb: misc: legousbtower: Fix memory leak
    - USB: ene_usb6250: fix DMA to the stack
    - watchdog: pcwd_usb: fix NULL-deref at probe
    - char: lp: fix possible integer overflow in lp_setup()
    - USB: core: replace %p with %pK
    - ARM: tegra: paz00: Mark panel regulator as enabled on boot
    - tpm_crb: check for bad response size
    - infiniband: call ipv6 route lookup via the stub interface
    - dm btree: fix for dm_btree_find_lowest_key()
    - dm raid: select the Kconfig option CONFIG_MD_RAID0
    - dm bufio: avoid a possible ABBA deadlock
    - dm bufio: check ...

[Thorsten Leemhuis (thleemhuis)]

> Given that and assuming it still has the large performance improvement on newer kernel
> I think it's worth an attempt to submit upstream along with the test data.

Did anyone do this and can point me to the discussion in the archives?

FWIW, from *a quick look* it seems the patch that was applied looks like a variant of the patch discussed in https://patchwork.kernel.org/patch/5784701/ One of the core Linux kernel network developers there answered the question "Does this look ok/safe as a solution to you?" with "Not at all." (see Link for more details)

[AceLan Kao (acelankao)]

This is the in progress discussion thread
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041