Changes between Version 11 and Version 12 of wireless/wifi


Ignore:
Timestamp:
01/16/2018 11:17:46 AM (6 weeks ago)
Author:
Tim Harvey
Comment:

added section on TCP Congestion control and TCP Small Queue (TSQ) tuning

Legend:

Unmodified
Added
Removed
Modified
  • wireless/wifi

    v11 v12  
    555555
    556556===== Troubleshooting =====
    557 If encountering bad TCP performance with ath10k cards (ie ~20Mbits/s):
    558  * Try changing the congestion algorithm via
    559  {{{
    560 # "cubic" and "reno" algorithms are built by default
    561 echo reno > /proc/sys/net/ipv4/tcp_congestion_control
    562 }}}
     557If encountering bad TCP performance with MIMO cards (typically ath10k):
     558 * see [wiki:wireless/wifi#tcp_cong TCP Congestion Control]
     559 * see [wiki:wireless/wifi#tsq TCP Small Queues]
    563560
    564561If encountering issues:
    565 
    566 * {{{hostapd-conf}}} was written for and takes advantage of the bash shell, make sure you aren't running it with another shell program (ie Ubuntu's default "dash" shell)
    567 * ensure both hostapd and wpa_supplicant are not both trying to manage the interface (ie you have it configured for both AP and Client mode)
    568 * ensure your client can see the AP (ie {{{iw dev wlan0}}} scan for a Linux client, or use a wireless scanner such as 'Wifi Analyzer' on an Android device)
    569 * For client mode ensure the kernel shows that you are associated with the AP. You should see {{{wlan0: associated}}} in the kernel messages
    570 * check your encryption settings
    571 * if you can ping between the AP and the client directly but not get through them:
    572  * check your routing configuration (ie via {{{route -n}}} on Linux) and make sure you have a proper gateway
    573  * if trying to bridge wireless to ethernet networks ensure 'both' the AP and the Client have 4addr header parsing enabled
    574 * if DNS resolution is not occurring first make sure you can ping the nameserver by IP
     562 * {{{hostapd-conf}}} was written for and takes advantage of the bash shell, make sure you aren't running it with another shell program (ie Ubuntu's default "dash" shell)
     563 * ensure both hostapd and wpa_supplicant are not both trying to manage the interface (ie you have it configured for both AP and Client mode)
     564 * ensure your client can see the AP (ie {{{iw dev wlan0}}} scan for a Linux client, or use a wireless scanner such as 'Wifi Analyzer' on an Android device)
     565 * For client mode ensure the kernel shows that you are associated with the AP. You should see {{{wlan0: associated}}} in the kernel messages
     566 * check your encryption settings
     567 * if you can ping between the AP and the client directly but not get through them:
     568  * check your routing configuration (ie via {{{route -n}}} on Linux) and make sure you have a proper gateway
     569  * if trying to bridge wireless to ethernet networks ensure 'both' the AP and the Client have 4addr header parsing enabled
     570 * if DNS resolution is not occurring first make sure you can ping the nameserver by IP
    575571
    576572=== wpa-supplicant ===
     
    727723 * CPU factors:
    728724  * CPU performance bottleneck (which can be verified by watching output of 'top' while doing performance tests) can vary greatly based on SMP configuration, IRQ configuration, kernel netfilter modules, userspace services, and CPU cache configuration:
     725 * TCP Congestion control (affecting TCP performance)
     726  * see [wiki:wireless/wifi#tcp_cong TCP Congestion Control]
     727  * see [wiki:wireless/wifi#tsq TCP Small Queues]
    729728
    730729Additional References:
     
    803802== !WiFi Terminology and Concepts ==
    804803
     804
     805[=#tcp_cong]
     806=== TCP Congestion Control ===
     807Starting in Linux 2.6.7 (and back-ported to 2.4.27), Linux includes alternative congestion control algorithms beside the traditional 'reno' algorithm. 2.6.13 added support for plug-able congestion control algorithms set using sysctl variable net.ipv4.tcp_congestion_control which is set to bic/cubic or reno by default depending on kernel versions.
     808
     809The Internet has predominantly used loss-based congestion control (largely Reno or CUBIC) since the 1980s, relying on packet loss as the signal to slow down. While this worked well for many years, loss-based congestion control is unfortunately out-dated in today's networks. On today's Internet, loss-based congestion control causes the infamous bufferbloat problem, often causing seconds of needless queuing delay, since it fills the bloated buffers in many last-mile links. On today's high-speed long-haul links using commodity switches with shallow buffers, loss-based congestion control has abysmal throughput because it over-reacts to losses caused by transient traffic bursts.
     810
     811TCP congestion control algorithms can be configured in the Kenrel under 'Networking support (NET) -> Networking options -> TCP/IP networking (INET) -> TCP: advanced congestion control (TCP_CONG_ADVANCED). The default is typically CONFIG_TCP_CONG_CUBIC which builds in CUBIC (default) and Reno. A more modern algorithm called BBR [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/ipv4/Kconfig?id=0f8782ea14974ce992618b55f0c041ef43ed0b78 was introduced more recently].
     812
     813You can select between multiple TCP congestion control algorithms via userspace sysctl:
     814{{{#!bash
     815cat /proc/sys/net/ipv4/tcp_available_congestion_control # see available algos
     816sysctl net.ipv4.tcp_congestion_control=reno # select Reno
     817}}}
     818
     819References:
     820 - https://fasterdata.es.net/host-tuning/linux/expert/
     821 - https://linuxgazette.net/135/pfeiffer.html
     822 - https://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf
     823
     824
     825[=#tsq]
     826=== TCP Small Queues (TSQ) ===
     827TCP Small Queues (TSQ) performs local flow control, limiting the amount of data in the queues on the sending host. Like TSO autosizing, TSQ has its own balancing act, keeping the queues small to reduce latency and head-of-line blocking (HoLB), while keeping the queues just large enough to ensure the queues on the sending host.
     828
     829The kernel TSQ logic allows up to 1ms of bytes to be queued into qdisc and driver queues. However, Wifi aggregation (multiple streams) needs a bigger budget to allow bigger rates to be discovered by various TCP Congestion Control algos.
     830
     831A [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e patch] has made it into the 4.15 kernel that allows wifi drivers to adjust this value as needed but drivers need to be updated to add this functionality.
     832
     833Gateworks has a [https://github.com/Gateworks/linux-newport/commit/64f1fcb3f7a7715dc6fa1e8b30f02f01032fb2dd patch] in the Newport kernel that allows userspace to change the default 1ms buffering time manually with sysctl. Increasing the buffering to something between 1ms and 9ms shows significant throughput increases for MIMO cards. For example:
     834{{{#!bash
     835sysctl net.ipv4.tcp_tsq_limit_output_interval=5 # use 5ms of buffering in TSQ logic
     836}}}
     837
     838References:
     839- [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041 Ubuntu bug with discussion]
     840- [https://github.com/Gateworks/linux-newport/commit/64f1fcb3f7a7715dc6fa1e8b30f02f01032fb2dd Patch allowing userspace configuration of TSQ buffer time via sysctl]
     841- [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e patch Linux 4.15 patch to allow wifi drivers to adjust the TSQ buffer size]
     842- [https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=111b49902465116a8353d29afe02eff0f56ea0a3 patch in LEDE adjusting TSQ logic]
     843
     844
     845[=#mac80211]
    805846=== mac80211 ===
    806847mac80211 refers to the Linux kernel 802.11 MAC layer software stack written for !SoftMAC radios. For many years all radio drivers utilize this layer and those drivers are referred to as 'mac80211 drivers'. An exception to this would be the popular 'madwifi' driver used for Atheros AR5XXX based 802.11abg radios (the mac80211 driver alternative to madwifi is the ath5k driver).