Slow wifi speeds temporarily on boot

Issues & Assistance Networking Support
1

Almost every time I boot up Garuda, my wifi becomes incredibly slow (to the point where it is not working) for a minute or two, before going back to its normal speeds.

When I am trying to load applications such as Discord, Firefox, websites do not load, and I am stuck waiting until I open the wifi widget and click on my wifi connection (i am not changing any settings, just clicking on the network) and then suddenly it appears to work again. unsure if there is any connection between the two.

System:
Kernel: 6.1.6-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=a1233120-7f2f-4c58-a196-55928510cccc rw rootflags=subvol=@
quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
loglevel=3 ibt=off
Desktop: KDE Plasma v: 5.26.5 tk: Qt v: 5.15.8 info: latte-dock
wm: kwin_x11 dm: SDDM Distro: Garuda Linux base: Arch Linux
Machine:
Type: Desktop Mobo: Gigabyte model: B450M H serial: N/A UEFI: American
Megatrends LLC. v: F63 date: 08/03/2022
CPU:
Info: model: AMD Ryzen 5 5600G with Radeon Graphics socket: AM4 bits: 64
type: MT MCP arch: Zen 3 gen: 4 level: v3 note: check built: 2021-22
process: TSMC n7 (7nm) family: 0x19 (25) model-id: 0x50 (80) stepping: 0
microcode: 0xA50000D
Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 3 MiB desc: 6x512 KiB
L3: 16 MiB desc: 1x16 MiB
Speed (MHz): avg: 1608 high: 3900 min/max: 1400/4464 boost: enabled
base/boost: 3900/4450 scaling: driver: acpi-cpufreq governor: schedutil
volts: 1.4 V ext-clock: 100 MHz cores: 1: 1400 2: 1400 3: 1400 4: 1400
5: 1400 6: 1400 7: 3900 8: 1400 9: 1400 10: 1400 11: 1400 12: 1400
bogomips: 93431
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Vulnerabilities: <filter>
Graphics:
Device-1: AMD Cezanne [Radeon Vega Series / Radeon Mobile Series]
vendor: Gigabyte driver: amdgpu v: kernel arch: GCN-5.1 code: Vega-2
process: TSMC n7 (7nm) built: 2018-21 pcie: gen: 3 speed: 8 GT/s lanes: 16
link-max: gen: 4 speed: 16 GT/s ports: active: DP-1,HDMI-A-1 empty: none
bus-ID: 0a:00.0 chip-ID: 1002:1638 class-ID: 0300 temp: 30.0 C
Display: x11 server: X.Org v: 21.1.6 with: Xwayland v: 22.1.7
compositor: kwin_x11 driver: X: loaded: amdgpu unloaded: modesetting
alternate: fbdev,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
Screen-1: 0 s-res: 3840x1080 s-dpi: 96 s-size: 1016x285mm (40.00x11.22")
s-diag: 1055mm (41.54")
Monitor-1: DP-1 mapped: DisplayPort-0 pos: left model: AOC 2450W
built: 2012 res: 1920x1080 hz: 60 dpi: 94 gamma: 1.2
size: 521x293mm (20.51x11.54") diag: 598mm (23.5") ratio: 16:9 modes:
max: 1920x1080 min: 720x400
Monitor-2: HDMI-A-1 mapped: HDMI-A-0 pos: primary,right
model: Philips PHL 271V8 serial: <filter> built: 2021 res: 1920x1080 dpi: 82
gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9
modes: max: 1920x1080 min: 720x400
API: OpenGL v: 4.6 Mesa 22.3.3 renderer: AMD Radeon Graphics (renoir LLVM
14.0.6 DRM 3.49 6.1.6-zen1-1-zen) direct render: Yes
Audio:
Device-1: AMD Renoir Radeon High Definition Audio driver: snd_hda_intel
v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16 link-max: gen: 4
speed: 16 GT/s bus-ID: 0a:00.1 chip-ID: 1002:1637 class-ID: 0403
Device-2: AMD Family 17h/19h HD Audio vendor: Gigabyte
driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
link-max: gen: 4 speed: 16 GT/s bus-ID: 0a:00.6 chip-ID: 1022:15e3
class-ID: 0403
Sound API: ALSA v: k6.1.6-zen1-1-zen running: yes
Sound Server-1: PulseAudio v: 16.1 running: no
Sound Server-2: PipeWire v: 0.3.64 running: yes
Network:
Device-1: Realtek RTL8192EE PCIe Wireless Network Adapter driver: rtl8192ee
v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: e000 bus-ID: 06:00.0
chip-ID: 10ec:818b class-ID: 0280
IF: wlp6s0 state: up mac: <filter>
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: Gigabyte driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s
lanes: 1 port: d000 bus-ID: 08:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: enp8s0 state: down mac: <filter>
IF-ID-1: virbr0 state: down mac: <filter>
Drives:
Local Storage: total: 2.27 TiB used: 110.21 GiB (4.7%)
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Crucial model: CT500P1SSD8
size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
lanes: 4 type: SSD serial: <filter> rev: P3CR021 temp: 31.9 C scheme: GPT
SMART: yes health: PASSED on: 155d 5h cycles: 670
read-units: 8,941,731 [4.57 TB] written-units: 24,710,039 [12.6 TB]
ID-2: /dev/sda maj-min: 8:0 type: USB vendor: Western Digital
model: WD20EARX-00PASB0 size: 1.82 TiB block-size: physical: 512 B
logical: 512 B type: N/A serial: <filter> rev: 0001 scheme: MBR
SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Partition:
ID-1: / raw-size: 232.63 GiB size: 232.63 GiB (100.00%)
used: 110.18 GiB (47.4%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p4
maj-min: 259:4
ID-2: /boot/efi raw-size: 512 MiB size: 511 MiB (99.80%)
used: 30.2 MiB (5.9%) fs: vfat block-size: 512 B dev: /dev/nvme0n1p1
maj-min: 259:1
ID-3: /home raw-size: 232.63 GiB size: 232.63 GiB (100.00%)
used: 110.18 GiB (47.4%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p4
maj-min: 259:4
ID-4: /var/log raw-size: 232.63 GiB size: 232.63 GiB (100.00%)
used: 110.18 GiB (47.4%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p4
maj-min: 259:4
ID-5: /var/tmp raw-size: 232.63 GiB size: 232.63 GiB (100.00%)
used: 110.18 GiB (47.4%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p4
maj-min: 259:4
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 14.99 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 35.6 C mobo: N/A gpu: amdgpu temp: 32.0 C
Fan Speeds (RPM): N/A
Info:
Processes: 309 Uptime: 8m wakeups: 0 Memory: 14.99 GiB
used: 4.53 GiB (30.2%) Init: systemd v: 252 default: graphical
tool: systemctl Compilers: gcc: 12.2.0 Packages: pm: pacman pkgs: 1600
libs: 483 tools: octopi,pamac,paru,yay Shell: garuda-inxi (sudo)
default: Bash v: 5.1.16 running-in: konsole inxi: 3.3.24
Garuda (2.6.14-1):
System install date:     2022-12-31
Last full system update: 2023-01-18
Is partially upgraded:   No
Relevant software:       snapper NetworkManager mkinitcpio
Windows dual boot:       Yes
Failed units:            systemd-vconsole-setup.service
2

Was this happening since you first installed, or did the delay start after updating?

If this delay started afterwards, then try installing the linux-lts kernel to see if there is any improvement.

3 Likes
3

i dont remember exactly but i think that this has kept happening since first install date

4

I usually like to blame any unusual wifi issues on dual booting with Windows. :wink: :rofl:

Disable your wifi's power saving option from within Windows device manager's advanced tab. Also be sure you have fast startup disabled.

Select your wifi connection in Network Manager and apply these settings:

“All users may connect to this network”

“Automatically connect to this network when it is available”

“Store password for all users (not encrypted)”

After this disable MAC Address randomization and then shutdown your laptop. Then remove the battery and power supply for a few minutes. After you've done that, restart both your router and computer. See if things behave exactly the same after performing that procedure.

Please search the forum/Internet if you are unfamiliar with any of these procedures.

It would also be useful if you could provide the following information:

Does the same issue exist when you boot from a Garuda live environment?

Please post the inputs and outputs of the following commands.

ping -c5 google.com; ping -c5 8.8.8.8

Run these commands immediately after startup when your connectivity is limited, and then rerun the commands once your internet speed has returned to normal.

3 Likes
5

for some reason the issue stopped happening? i wrote more about it at the bottom of this reply. i already began writing this reply when this started happening.

just a question - what does removing the battery/power supply do? also just to clarify i have a PC, not a laptop. also, if you want me to remove the power supply, it is ok if i just turn the power supply off right? not unplug it from everything? because that is a major hassle.

in response to your questions:

  • it is hard to tell if the issue exists in a live environment. if i am in a live environment the network connection is fine, but as stated before it is difficult to tell because it is:
  1. the first time connecting, and the wireless connection worked flawlessly on first ever connection of wifi - it just breaks afterwards.
  2. it does not auto-connect to the wifi, which is something that i do on my current install, and might be the cause of an issue, not sure.

output when internet is normal:

╰─λ ping -c5 google.com
PING google.com (142.250.71.78) 56(84) bytes of data.
64 bytes from syd15s17-in-f14.1e100.net (142.250.71.78): icmp_seq=1 ttl=116 time=14.5 ms
64 bytes from syd15s17-in-f14.1e100.net (142.250.71.78): icmp_seq=2 ttl=116 time=50.2 ms
64 bytes from syd15s17-in-f14.1e100.net (142.250.71.78): icmp_seq=3 ttl=116 time=75.0 ms
64 bytes from syd15s17-in-f14.1e100.net (142.250.71.78): icmp_seq=4 ttl=116 time=98.8 ms
64 bytes from syd15s17-in-f14.1e100.net (142.250.71.78): icmp_seq=5 ttl=116 time=19.9 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 14.498/51.696/98.833/32.116 ms

╰─λ ping -c5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=31.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=53.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=26.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=98.6 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=115 time=18.3 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 18.294/45.670/98.605/28.963 ms

UPDATE: i was trying to replicate the issue. but for some reason, it is no longer working - i havent followed your tutorial or changed anything, but for some reason whenever i restart, shut down, or put my computer on sleep, the issue is no longer there. it was happening nearly every time before, but somehow it has stopped? i have no idea why this is happening. but i am not sure if this is a permanent fix or just luck. the network connectivity issue usually happens every time.

also i have not updated the packages in my computer in quite some time, so i do not think it has something to do with my packages, although i am not 100% sure on this.

would this issue perhaps have something to do with the period of time between restarting? i always shut down my computer and when i wake up and boot up my computer the issue always occurs. might be a dumb idea but just speculation.

6

This sometimes helps if Windows is interfering with your wifi operation (with its power saving features) when using Linux.

If you are using a desktop rather than a laptop, then unplugging the power cord from the wall socket for a minute or two is usually sufficient.

Sometimes, simply booting to a live environment is enough to reset whatever was causing the issue. This may not be a lasting fix, but it does help in some rare situations.

I’m glad to hear you’ve got things working properly for now. Hopefully things continue working correctly for you.

3 Likes
7

Just woke up and booted up my computer and the issue happened briefly again. I thought that everything was back to normal but when I was trying to go on YouTube, it was not loading for a significant amount of time. So clearly the issue is still present unfortunately. I will do the steps that you have told me to do and update you on whether or not it was effective.

UPDATE: I did the steps that you told me to do, and so far nothing has gone wrong. But as stated earlier, the issue is still there when I woke up, and is likely to happen again when I wake up tomorrow morning.

8

Hi. Just woke up again and issue happened again. This was result of ping -c5 8.8.8.8:

╰─λ ping -c5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=195 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=141 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 2 received, 60% packet loss, time 4042ms
rtt min/avg/max/mdev = 141.274/167.999/194.724/26.725 ms

clearly issue is still happening, so still a bit confused

9

This time I put my computer on sleep and when I woke up, this was my output to your commands:

╰─λ ping -c5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.16 icmp_seq=1 Destination Host Unreachable
From 192.168.1.16 icmp_seq=2 Destination Host Unreachable
From 192.168.1.16 icmp_seq=3 Destination Host Unreachable
From 192.168.1.16 icmp_seq=4 Destination Host Unreachable
From 192.168.1.16 icmp_seq=5 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4075ms
pipe 3

Then I restarted my computer and did the same command again - the speed was very very slow compared to normal. So the issue is still present.

╰─λ ping -c5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=172 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=121 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=56.0 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 3 received, 40% packet loss, time 4034ms
rtt min/avg/max/mdev = 55.961/116.430/172.033/47.511 ms
10

Your loss of connectivity after suspension can sometimes be corrected with a different kernel. I would test out at least the linux-mainline and linux-lts kernels. You should also check to see if there is a bios update available for your mobo.

2 Likes
11

I have already updated my mobo to latest BIOS.

I have tried using linux-mainline, and the issue persists, but it is not as bad (there is a connection but it is just very slow). However, on mainline, at times I randomly disconnect from my connection for no reason.

LTS has similar issues.

12

Hi please help with my issue it is still persisting.

13

can you ping your gateway address i,e 192.168.1.1 and provide output

1 Like
14

Just FYI.

Helpers on the forum also have a life, and begging and pleading for help is unappreciated. Helpers will get back to you as soon as they have some spare time to assist you. Most forum helpers find empty bumps a complete turn off. Empty bumps mostly tend to just get you a bad reputation and often result in even less assistance on any technical help forum. Our forum strongly discourages our users from attempting to elevate their threads position by posting a comment without any substance (bumping).

Instead of bumping:

Continue your troubleshooting efforts, then post a detailed record of everything you have tested. Also post any related information you have uncovered online that may pertain to your issue, (be sure to post links). This demonstrates that you are being proactive by continuing to research and troubleshoot on your own (even if others aren’t currently offering suggestions). Posting a detailed synopsis shows forum helpers that you are motivated and are attempting to work through your issues yourself. This goes a long ways towards getting good will, as this shows you are self motivated and not just expecting others to fix your problem. This is actually a very important factor, because helpers on the forum are far more likely to respond to users who demonstrate they are not lazy and don’t require being spoon fed every answer. This is how responsible forum users bring further attention to their issue and gain more assistance.

So to reiterate, please do not bump!!!

7 Likes
15

Now, back to your original issue.

Your problem can likely be sidestepped by writing a systemd service. Generally I prefer to exhaust all the proper fixes to correct the actual cause of the issue, rather than employing a workaround. The systemd service that I've created for you should restart your network connection at login. This should hopefully give you a proper working network connection shortly after you login. There could be up to a 15 sec delay restarting your network connection, but that seems far preferable to your present situation.

Follow the steps I have detailed below to create a service that should restart your network connection, (without requiring any intervention on your part at login).

Network Restart Service:

Create the following service file with a root capable text editor such as KDE's Kate, or with a terminal based text editor such as Micro:

Service file name:

/etc/systemd/system/network-restart.service

Add the following contents to the service file:

#/etc/systemd/system/network-restart.service
#sudo systemctl enable network-restart.service
#sudo systemctl start network-restart.service
#systemctl status network-restart.service

[Unit]
Description=Network Restart Service 
After=network.target multi-user.target sddm.service 
Requires=sddm.service
StopWhenUnneeded=yes

[Service]
User=root
Type=oneshot
RemainAfterExit=yes
Restart=always 
RestartSec=3
ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking off'
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/systemctl stop NetworkManager
ExecStart=/usr/bin/ip link set wlp6s0  down
ExecStart=/usr/bin/modprobe -r  rtl8192ee
ExecStart=/usr/bin/sleep 5
ExecStart=/usr/bin/modprobe rtl8192ee
ExecStart=/usr/bin/sleep 3
ExecStart=/usr/bin/ip link set wlp6s0 up
ExecStart=/usr/bin/sleep 2
ExecStart=/usr/bin/systemctl start NetworkManager
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking on'
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli r wifi off'
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli r wifi on'

[Install]
WantedBy=multi-user.target

Once you have created and saved the above service file, enable the service with the following terminal command :

sudo systemctl enable network-restart.service

After issuing that command, reboot your computer. Hopefully after you restart your computer your original issue will have been corrected.

Notes pertaining to the above service:

The sleep units in the above service may be reduced, (or eliminated) if the service creates a network restart delay that you find excessive. It may take up to 15 seconds to restart all network components post-login. You should however be cautious about doing this, as lowering or eliminating the sleep times may harm the reliability of the service.

The following section only applies to other users trying to replicate this service on a different system than the OP, (originator of this thread).

For the benefit of others attempting to implement the above service on their own system, you will likely need to adapt the service to reflect your own specific system components as follows:

If your network adapter's designation is different than wlp6s0 you will need to substitute you own adapter’s ID into the service file.

If you are using a different network driver module, you will also need to substitute it in place of rtl8192ee.

If you are using a different display manager than KDE's sddm, then you will also need to substitute your display manager in place of sddm.service, (as this service is intended for use with KDE).

Good luck.

4 Likes
16

sorry for bumping - i understand the implications of posting an empty reply and will try my hardest to not do it again.

for your solution, it would have the delay up to 15 seconds every time i boot up?

when i use the mainline-kernel, the delay is around 5-10 seconds, and it can be resolved if i open the wifi widget on the top bar. it is the zen and lts kernel that take incredibly longer times.

also, is this the only option left? because this fix would still be a bit annoying. the entire point of raising this issue was so that i could have this issue fixed and never have to deal with the slowed speeds at all, but this clearly would not be perfect.

17

so true I have been doing that Lately and its been helping a lot

1 Like
18

I guess you really won’t know until you try.

You can remove or comment out all the lines invoking seconds of sleep in the service if you want zero delay. This may, or may not affect the service adversely. Sometimes without the units of sleep the service will not consistently restart the network connection. Again, you will never know unless you test it out for yourself. Generally I’ve found that slower/older computers require sleep times or the service may fail. Newer/faster computers may be able to restart the network connection without seconds of sleep between each step. Play with it and you will find out for yourself. I can not predict the outcome on your system, only you can determine if running a service will result in an improvement for you.

Try it, you may like it. :wink:

4 Likes
19

Ok I have tried using the script for about a week.

Unfortunately your script does not solve the problem - after waiting 15 seconds there is still wifi issue. I cannot login to YouTube or go on the Garuda Linux forums.

20

Unfortunately, your last post really tells me very little.

cat /etc/systemd/system/network-restart.service

Please post the output of the above commands.

1 Like