Googleですべて検索してUbuntuに尋ねた後、問題の修正が見つかりませんでした:デュアルブートでWindows 10およびUbuntu 16.04を実行しているDell XPS 13があり、インターネットダウンロード速度は問題なく動作しますが、アップロード速度はway Windowsでの速度よりも遅い。正直なところ、その方法で作業を行うことはできません。
インターネットのテスト結果は次のとおりです:
$ curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python -
Retrieving speedtest.net configuration...
Testing from Bezeq International (79.176.94.28)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Partner (Tel Aviv) [1.56 km]: 30.989 ms
Testing download speed................................................................................
Download: 33.93 Mbit/s
Testing upload speed................................................................................................
Upload: 0.15 Mbit/s
の結果:Sudo lshw -C net
:
$ Sudo lshw -C net
[Sudo] password for liorscha:
*-network
description: Wireless interface
product: QCA6174 802.11ac Wireless Network Adapter
vendor: Qualcomm Atheros
physical id: 0
bus info: pci@0000:3a:00.0
logical name: wlp58s0
version: 32
serial: 9c:b6:d0:e6:d5:79
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=ath10k_pci driverversion=4.13.0-38-generic firmware=WLAN.RM.4.4.1-00051-QCARMSWP-1 ip=10.0.0.15 latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:286 memory:dc000000-dc1fffff
iwlist wlan0 s
:の結果
wlan0 Interface doesn't support scanning.`
lsmod | grep ath10
:の結果
ath10k_pci 45056 0
ath10k_core 352256 1 ath10k_pci
ath 28672 1 ath10k_core
mac80211 782336 1 ath10k_core
cfg80211 614400 3 mac80211,ath,ath10k_core
これらは私がすでに試したものです:
編集
これ 解決しました。
これは bug の影響を受けているようです。問題と提案の68の投稿があります。最新の提案は:
1年以上前に、元の回答が投稿された後、バグ修正が行われました。これは、カーネル4.16-rc5
リリースおよび ソースコード変更コメント 状態で発生しました。
Sk_pacing_shiftの異なる値のスループットを達成しました(WiFiホップの反対側のホストに対する10秒のnetperf実行の平均5回の繰り返し):
- sk_pacing_shift 10:43.21 Mbps(プリパッチ)
- sk_pacing_shift 9:78.17 Mbps
- sk_pacing_shift 8:123.94 Mbps
- sk_pacing_shift 7:128.31 Mbps
この変更により、競合するフローの遅延が〜3ミリ秒から〜10ミリ秒に増加します。これは、WiFiデバイス自体から発信されたものではない(したがって、TSQによって制限されない)フローによって引き起こされるキューイング遅延とほぼ同じ大きさです。
サインオフ:TokeHøiland-Jørgensen
直観的に、バグ修正を取得するには4.15
より大きいカーネルが必要だと思います。次のセクションで説明するように、これはそうではありません。
4.14.114
LTSにあります私はまだカーネル4.14.xxx
LTS(Long Term Support)を使用しています。これにはさらに5年間のアップデートがありますinclude4.16
上記のパッチと最近のカーネル5.0
バグ修正。
バグ修正を証明するために、現在のカーネル4.14.114
がどこにあるかを確認します:
それは言います:
ビルド元のソースを取得するには、以下のコミットをフェッチします。
git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack v4.14.114
All commits
を選択しますAdjust TSQ pacing shift
と入力します。Expand
をクリックすると、以下が表示されます@ WinEunuuchs2Unixが投稿したように、この問題は bug#1670041 に関連していることを確認できます。参考までに、私のPCI-EワイヤレスアダプターはTP-LINK TL-WDN4800
:
lspci -nn |grep -i wireless
Network controller [0280]: Qualcomm Atheros AR93xx Wireless Network Adapter [168c:0030] (rev 01)
Ath10kのTCPストリームを送信する際の低スループットは、このmac80211コミットで修正する必要があります。
mac80211:TSQペーシングシフトの調整
https://git.kernel.org/linus/36148c2bbfbe50c50206b6f61d072203c80161e
どうやらv4.16-rc5がそのコミットを持っている最初のリリースでした。
カーネルを4.17(以前は4.14 LTS)にアップグレードすると、これが修正されます。