Score:0

Slow Painful WiFi speed Ubuntu

tt flag

I dual booted Ubuntu 18.04.5 with Windows 10 Pro 21h1.

In windows and all other devices I'm getting 50 Mbps but when I use Ubuntu 18.04.5 I get 1Mbps max. In WiFi settings it displays link speed as same.

Here are the configs

wlp3s0    IEEE 802.11  ESSID:"SSID"  
      Mode:Managed  Frequency:2.432 GHz  Access Point: 00:00:00:00:00   
      Bit Rate=1 Mb/s   Tx-Power=20 dBm   
      Retry short limit:7   RTS thr:off   Fragment thr:off
      Power Management:off
      Link Quality=51/70  Signal level=-59 dBm  
      Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
      Tx excessive retries:0  Invalid misc:27   Missed beacon:0

Look at the BitRate here.

*-network
   description: Wireless interface
   product: QCA9377 802.11ac Wireless Network Adapter
   vendor: Qualcomm Atheros
   physical id: 0
   bus info: pci@0000:03:00.0
   logical name: wlp3s0
   version: 31
   serial: 00:00:00:00:00:00
   width: 64 bits
   clock: 33MHz
   capabilities: bus_master cap_list ethernet physical wireless
   configuration: broadcast=yes driver=ath10k_pci driverversion=5.4.0-81-generic firmware=WLAN.TF.2.1-00021-QCARMSWP-1 ip=xxx.xxx.xxx.xx latency=0 link=yes multicast=yes wireless=IEEE 802.11
   resources: irq:131 memory:b4000000-b41fffff

It gives okay speed with mobile hotspot but behaves like a snail with WiFi router only.

I turned off the power management for the wlp3s0.

I found something in /etc/modprobe.d/blacklist-ath_pci.conf saying

# For some Atheros 5K RF MACs, the madwifi driver loads buts fails to
# correctly initialize the hardware, leaving it in a state from
# which ath5k cannot recover. To prevent this condition, stop
# madwifi from loading by default. Use Jockey to select one driver
# or the other. (Ubuntu: #315056, #323830)
blacklist ath_pci

I can sense some problem with the iwlwifi.conf as well but as much as I understand it's a driver for Intel hardware but my WiFi is Qualcomm so I don't know what that have to do with it.

I have tried several others remedies which Google and Youtube offers but the Bit Rate remains the same as 1 Mb/s.

Any Help would be appreciated.

edit 1.0 : My phone supports enabling WiFi and Hotspot at the same time so I connect my phone to the router and Ubuntu machine to the phone's hotspot. It lead to getting 20Mbps on Ubuntu Machine. (It's link speed still shows 1 Mbps anyhow). However the router to Ubuntu Machine speed is 0.25-1.0 Mbps.

Yuri Sucupira avatar
cn flag
Have you tried optimizing the connection's default MTU (maximum transmission unit)? Assuming that the SSID of your problematic wi-fi network is *badwifi*, connect to it and then run this command in the terminal so you find the optimal MTU number for *badwifi*: `ping -c 3 -M do -s 9000 www.google.com`. Suppose that such command outputs **mtu=96**. Next, issue the command `sudo nano /etc/NetworkManager/system-connections/badwifi.nmconnection` and replace the `XXX` number at `mtu=XXX` so it reads `mtu=96`. Save it with **Ctrl O** and exit the editor with **Ctrl X**, then reboot.
Tungsten07 avatar
tt flag
I recently changed my MTU to 1492 from 1500 and `ping -c 3 -M do -s 9000 www.google.com` gave 100% packet loss. And after a few tweak I opened badwifi file and it have no mention of MTU.
Yuri Sucupira avatar
cn flag
The command `ping -c 3 -M do -s 9000 www.google.com` does give you 100% packet loss: it's intentional. But it also gives you the correct MTU. E.g. when I run `ping -c 3 -M do -s 9000 www.google.com` on my system it gives me this message: `ping: local error: message too long, mtu=96`. This means that I indeed had 100% packet loss (due to the preset MTU = 9000, which is extremely high on purpose), but it also informed me that the highest MTU value that won't give me such packet loss is 96. Hence, in my case, the ideal MTU is 96. You need to do the same test in your system.
Yuri Sucupira avatar
cn flag
Once you perform the test and check which is the MTU indicated for your *badwifi* network, run `sudo nano /etc/NetworkManager/system-connections/badwifi.nmconnection` (replace *badwifi* with the correct name/SSID of your wi-fi network), then at the `[wifi]` section of the file you can add the parameter `mtu=xxx` where `xxx` is the MTU recommended by the output of that test. Example: if the test informs you an ideal MTU of 96, then under `[wifi]` you must add the text `mtu=96`. E.g. `[wifi] <line break> band=bg <line break> (...) <line break> mode=infrastructure <line break> mtu=96`
Yuri Sucupira avatar
cn flag
If that `ping` command gives you e.g. mtu=1492 but setting mtu=1492 does not solve the issue for you, try starting your test with a very small value and then increasing it till you don't get a *pong* anymore: e.g. run `ping -c 3 -s 68 www.google.com`. If the ping receives a *pong* (i.e. a reply such as e.g. `76 bytes from 2800:3f0:4001:81f::2004 (2800:3f0:4001:81f::2004): icmp_seq=3 ttl=117 time=36.8 ms`, then repeat that command with 78 instead of 68. If you don't get a *pong*, decrease the number. When you find the highest number that receives a reply, add 28 to it: that's your ideal MTU.
Yuri Sucupira avatar
cn flag
E.g. suppose that `ping -c 3 -s 69 www.google.com` gives you an output/reply reporting 100% packet loss, and suppose that you then decrease 69 to 68 and then `ping -c 3 -s 68 www.google.com` gives you 0% packet loss. In such case, your ideal MTU is 68 + 28 = **96**, hence you must add a line with the text `mtu=96` up there under the `[wifi]` section in the file `/etc/NetworkManager/system-connections/badwifi.nmconnection`, then save the file, exit, reboot and then test your network performance.
Yuri Sucupira avatar
cn flag
Another example: if you get 100% packet loss for `ping -c 3 -s 773 www.google.com` but get 0% packet loss for `ping -c 3 -s 772 www.google.com`, then your ideal MTU is 772 + 28 = **800**, thus you must add a new line with the text `mtu=800` up there under the `[wifi]` section in the file `/etc/NetworkManager/system-connections/badwifi.nmconnection`, then save the file, exit, reboot and then test your network performance.
Tungsten07 avatar
tt flag
I gave me 1500 MTU and that is my current set value of MTU so I don't think MTU is a problem here.
Yuri Sucupira avatar
cn flag
Did you set MTU = 1500 based on the test results of the procedure that I previously described? I.e. does `ping -c 3 -s 1472 www.google.com` give you 0% packet loss?
Tungsten07 avatar
tt flag
I didn't set it per se, It was already 1500 and the results from the procedure you described it still said 1500. Anyway I solved the problem. I changed auto 20/40 Hz to 20Hz in router's settings and it's working way better now. Thanks for your help.
Score:1
in flag

This card is notorious for it's sluggishness. There is a 3rd-party firmware available if you'd like to give it a try, though.

Here's how to install it:

  1. Open Terminal (if it's not already open)
  2. Go to the firmware directory for the card:
    cd /lib/firmware/ath10k/QCA9377/hw1.0/
    
  3. Rename two existing files (so they're not lost)
    sudo mv firmware-5.bin firmware-5.bin.orig
    sudo mv firmware-6.bin firmware-6.bin.orig
    
  4. Get the 3rd-party firmware:
    sudo wget "https://github.com/kvalo/ath10k-firmware/blob/master/QCA9377/hw1.0/CNSS.TF.1.0/firmware-5.bin_CNSS.TF.1.0-00267-QCATFSWPZ-1?raw=true" -O firmware-5.bin
    
  5. Reload the kernel module:
    sudo modprobe -r ath10k_pci
    sudo modprobe ath10k_pci 
    sudo dmesg | grep ath10k
    

That should give you proper transmission speeds.

Tungsten07 avatar
tt flag
Sadly it reduced my speed from 1 Mbps to 0.25 Mbps. Thanks though.
Jeremy31 avatar
ke flag
That isn't third party firmware, Kalle Valo is a Qualcomm kernel dev
Score:0
it flag

Check your WiFi MTU, using

ip link

or

ip l | grep $(ip r | awk '/default/ {print $5}' ) | awk '{print $2, $4, $5}'

also notice your WiFi interface's name.

The MTU (Maximum Transmission Unit) is the size of the largest packet that can be sent in a single network transmission. If a packet exceeds the MTU of a link, the data must be split into multiple packets (fragmented). These multiple packets must be sent over the link, received, acknowledged, and reassembled at the far end. If your link is misconfigured, and you have to fragment every packet you send, your actual data transfer rate drops.

Ethernet (wired) networks use an MTU of 1500 bytes.

Due to additional per packet overhead for WiFi (8 bytes PPPoE header), WiFi uses an MTU of 1492.

Your MTU should be set by your DHCP server, check your router's config.

You can set your own MTU (setting does not persist over restarts) with

sudo ip link set dev name mtu 1492

where "name" is the interface name from above.

Here's an example:

walt@squid:~(0)$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp63s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:24:21:7f:e5:1c brd ff:ff:ff:ff:ff:ff
3: wlxf46d04b1790f: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether f4:6d:04:b1:79:0f brd ff:ff:ff:ff:ff:ff
walt@squid:~(0)$   sudo ip link set dev wlxf46d04b1790f mtu 1492
[sudo] password for walt: 
walt@squid:~(0)$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp63s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:24:21:7f:e5:1c brd ff:ff:ff:ff:ff:ff
3: wlxf46d04b1790f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether f4:6d:04:b1:79:0f brd ff:ff:ff:ff:ff:ff

My WiFi "interface name" is "wlxf46d04b1790f".

Tungsten07 avatar
tt flag
Thanks. I set it to 1492, it was 1500 earlier. But the transmission speed is same. Kindly look at edit 1 in question.
waltinator avatar
it flag
Install the `tracepath` package. Read `man tracepath`. `tracepath -n google.com` will show the best MTU (`tracepath` calls it Path MTU, `pmtu`).
Yuri Sucupira avatar
cn flag
@waltinator My ideal MTU is 96 (I mean: 68 + 28) and this is my current setting. `tracepath -n google.com` indeed gives me MTU = 96. But if I run e.g. `sudo ip link set dev name mtu 1492`, then `tracepath -n google.com` gives me MTU = 1492. I mean: usign `tracepath` isn't a reliable method. So far, the only way I found to figure out the actual maximum MTU that doesn't fragment is to run `ping -c 3 -s X www.google.com` increasing X until *pong* (i.e. ping's corresponding reply) fragments, then I decrease X by 1 unit until its ping's *pong* isn't fragmented, then I define MTU = such X + 28.
Yuri Sucupira avatar
cn flag
@waltinator In other words: in my case, `ping -c 3 -s 69 www.google.com` gave me 100% packet loss, then I executed `ping -c 3 -s 68 www.google.com` and it then gave me 0% packet loss. Hence, my ideal MTU is 68 + 28, i.e. MTU = 96. I then set my default MTU as 96 and, indeed, I noticed a great improvement in my WLAN's performance. I tried to explain this to Tungsten07 and I might be wrong, but I'm under the impression that so far he/she hasn't yet succeeded in performing this procedure and setting his/her ideal MTU correctly.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.