Internet seemingly throttled despite expected ping and speedtest-cli outputs

Ever since I switched from Windows to EndeavourOS, I’ve had network speed issues on this device. These are:
regardless of browser or program trying to download data;
regardless of the network I’m connected to;
regardless of using wired or wireless connection;
regardless of having recently loaded the same domain;
not the case on any other device connected to the network(s);
not visible on speedtest-cli (I see the expected 70Mbit/s);
not visible on ping 8.8.8.8 (I see the expected ~10ms with no spikes);
not visible on ping _gateway (I see the expected ~1ms);
visible on packetstats.com compared to other devices, frequently spiking to ~100ms;
mostly an issue on procedurally downloaded pages and videos, and the initial load of a page, though I don’t know of a consistent way to instead test active continual connection.

Here are some potentially useful outputs:

# lspci -k
03:00.0 Network controller: Intel Corporation Dual Band Wireless-AC 3168NGW [Stone Peak] (rev 10)
        DeviceName: WLAN
        Subsystem: Intel Corporation Device 2110
        Kernel driver in use: iwlwifi
# speedtest-cli
Retrieving speedtest.net configuration...
Testing from Plusnet (51.7.124.168)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by RETN (London) [141.88 km]: 13.778 ms
Testing download speed................................................................................
Download: 67.41 Mbit/s
Testing upload speed......................................................................................................
Upload: 19.65 Mbit/s
# ping 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=117 time=10.8 ms  
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=11.5 ms  
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=10.8 ms  
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=10.6 ms  
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=10.6 ms  
64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=10.6 ms  
64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=11.2 ms  
64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=10.9 ms  
^C  
--- 8.8.8.8 ping statistics ---  
8 packets transmitted, 8 received, 0% packet loss, time 7011ms  
rtt min/avg/max/mdev = 10.580/10.871/11.474/0.286 ms
# find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
avahi-daemon.service                     | multi-user.target.wants
avahi-daemon.socket                      | sockets.target.wants
bluetooth.service                        | bluetooth.target.wants
dbus-org.bluez.service                   | system
dbus-org.fedoraproject.FirewallD1.service | system
dbus-org.freedesktop.Avahi.service       | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service   | system
default.target                           | system
display-manager.service                  | system
firewalld.service                        | multi-user.target.wants
fstrim.timer                             | timers.target.wants
gcr-ssh-agent.socket                     | sockets.target.wants
getty@tty1.service                       | getty.target.wants
gnome-keyring-daemon.socket              | sockets.target.wants
iptables-restore.service                 | multi-user.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
nvidia-persistenced.service              | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
paccache.timer                           | timers.target.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
power-profiles-daemon.service            | graphical.target.wants
remote-fs.target                         | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
wireplumber.service                      | pipewire.service.wants
xdg-user-dirs-update.service             | default.target.wants
# pacman -Qs firmware
local/alsa-firmware 1.2.4-4
    Firmware binaries for loader programs in alsa-tools and hotplug firmware loader
local/b43-fwcutter 019-5
    firmware extractor for the b43 kernel module
local/dfu-util 0.11-3
    Tool intended to download and upload firmware using DFU protocol to devices connected over USB
local/edk2-ovmf 202311-1
    Firmware for Virtual Machines (x86_64, i686)
local/fwupd 1.9.22-2
    Simple daemon to allow session software to update firmware
local/linux-firmware 20240703.e94a2a3b-1
    Firmware files for Linux
local/linux-firmware-whence 20240703.e94a2a3b-1
    Firmware files for Linux - contains the WHENCE license file which documents the vendor license details
local/qemu-system-x86-firmware 9.0.2-1
    Firmware for QEMU system emulator for x86
local/sof-firmware 2024.06-1
    Sound Open Firmware
# dig heise.de # site I've never cached

; <<>> DiG 9.20.0 <<>> heise.de  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15637  
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1  
  
;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 512  
;; QUESTION SECTION:  
;heise.de.                      IN      A  
  
;; ANSWER SECTION:  
heise.de.               886     IN      A       193.99.144.80  
  
;; Query time: 13 msec  
;; SERVER: 192.168.1.254#53(192.168.1.254) (UDP)  
;; WHEN: Sat Aug 03 22:32:31 BST 2024  
;; MSG SIZE  rcvd: 53
# dig @8.8.8.8 heise.de

; <<>> DiG 9.20.0 <<>> @8.8.8.8 heise.de  
; (1 server found)  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40423  
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1  
  
;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 512  
;; QUESTION SECTION:  
;heise.de.                      IN      A  
  
;; ANSWER SECTION:  
heise.de.               5770    IN      A       193.99.144.80  
  
;; Query time: 13 msec  
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)  
;; WHEN: Sat Aug 03 22:32:55 BST 2024  
;; MSG SIZE  rcvd: 53

I wonder if this is the same issue I am having or related.
Doing a speed test it is OK.
Downloading an iso from a direct link or system update speed is very slow (in a few KB)
But browsing or even watching youtube is OK. Downloading through torrents is OK.

I wonder why and if it is related to OP!
I will follow this topic.

You should really open your own topic for your particular issue.

@laurapigeon
Do you have dual boot Windows or did you wipe and install EOS only. It could be the newer firmware? :thinking: I’m not sure what version it’s using. Maybe sudo dmesg will show?

Edit: You could also try setting this in

/etc/modprobe.d/iwlwifi.conf

add

options iwlwifi 11n_disable=1 swcrypto=1

Sorry. I didn’t mean to mess around! I just thought if it is the same issue it’s OK to just mention it. I didn’t mean to hijack a thread of course.

EOS only, installed via a ventoy live USB. My grub has LTS and normal, and some fallback version for each.

# sudo dmesg | grep firmware
[    5.274472] systemd[1]: Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67).
[    5.816435] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    5.889357] iwlwifi 0000:03:00.0: loaded firmware version 29.198743027.0 3168-29.ucode op_mode iwlmvm
[    5.903438] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq
[    6.518531] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)

I didn’t have a /iwlwifi.conf in the directory so I created it with only that line and rebooted the whole system. The issue is identical and other than the square bracket parts, the sudo dmesg | grep firmware is identical too.

Intel 7265D, 3165 and 3168’s latest firmware version is -29.ucode so it is using the correct firmware version.

Edit: Are you using 2.4 Ghz or 5Ghz on WiFi?

I don’t have my wifi connected in the network settings most of the time, just the wired connection. When it’s connected it says 5.18Ghz.

Here’s an example of the issue at work. The left part is via running speedtest-ctl and shows the speed I’d expect. The right part is scrolling as fast as possible through a google images search, getting halted for 3-5 seconds every time it needs to start to load more. Interestingly it also significantly increases the load on my CPU.

Have you tried 2.4 Ghz

  1. check the speed in your LAN using iperf, you should see values close to theoretical limits in a low load local network. Also check dns settings and route on your pc, maybe you have dead dns entries that cause delay while dropping to fallback, or routing is crappy for whatever reason. If that is all ok, there is no problem with your ps and you must look upstream.
  2. check the path to whatever destination in the internet you want by using mtr. You might see some hops somewhere in the path that drops packets. That is not so good. Check different destinations around the internet. For checking your router pick some destination that is very close to your router, some server from your provider for example, a content provider proxy, someting like that.

I have some new information that might be important. I went to testfile.org to try an actual large file download, and saw my network download speed peak in the exact same way as speedtest-cli. This seems to imply the issue is solely in downloading from multiple sources, or stopping and starting frequently.

I’m not certain how to interpret these iperf results, as I don’t often measure file transfers over LAN. They don’t appear to be throttled in the same way as the issue though.

# iperf3 -c 192.168.1.205 -t 5 # server and client both on eos machine

Connecting to host 192.168.1.205, port 5201  
[  5] local 192.168.1.205 port 32846 connected to 192.168.1.205 port 5201  
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd  
[  5]   0.00-1.00   sec   860 MBytes  7.21 Gbits/sec    0   1023 KBytes
[  5]   1.00-2.00   sec   964 MBytes  8.08 Gbits/sec    0   1023 KBytes
[  5]   2.00-3.00   sec   927 MBytes  7.78 Gbits/sec    0   1023 KBytes
[  5]   3.00-4.00   sec   989 MBytes  8.30 Gbits/sec    0   1023 KBytes
[  5]   4.00-5.00   sec   497 MBytes  4.16 Gbits/sec    0   1023 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -  
[ ID] Interval           Transfer     Bitrate         Retr  
[  5]   0.00-5.00   sec  4.91 GBytes  8.43 Gbits/sec    0   sender  
[  5]   0.00-5.00   sec  4.91 GBytes  8.43 Gbits/sec        receiver  
  
iperf Done.
# iperf3.exe -s # windows pc on network

Accepted connection from 192.168.1.205, port 49226
[  5] local 192.168.1.245 port 5201 connected to 192.168.1.205 port 49232
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   108 MBytes   907 Mbits/sec
[  5]   1.00-2.00   sec   113 MBytes   947 Mbits/sec
[  5]   2.00-3.00   sec   113 MBytes   949 Mbits/sec
[  5]   3.00-4.00   sec   113 MBytes   949 Mbits/sec
[  5]   4.00-5.00   sec   113 MBytes   947 Mbits/sec
[  5]   5.00-5.05   sec  5.17 MBytes   940 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-5.05   sec  0.00 Bytes   0.00 bits/sec    sender
[  5]   0.00-5.05   sec   565 MBytes   940 Mbits/sec   receiver


# iperf3 -c 192.168.1.245 -t 5 # eos machine

Connecting to host 192.168.1.245, port 5201  
[  5] local 192.168.1.205 port 49232 connected to 192.168.1.245 port 5201  
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd  
[  5]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0    211 KBytes
[  5]   1.00-2.00   sec   113 MBytes   947 Mbits/sec    0    211 KBytes
[  5]   2.00-3.00   sec   113 MBytes   949 Mbits/sec    0    211 KBytes
[  5]   3.00-4.00   sec   113 MBytes   948 Mbits/sec    0    211 KBytes
[  5]   4.00-5.00   sec   113 MBytes   947 Mbits/sec    0    211 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -  
[ ID] Interval           Transfer     Bitrate         Retr  
[  5]   0.00-5.00   sec   566 MBytes   950 Mbits/sec    0    sender  
[  5]   0.00-5.00   sec   565 MBytes   948 Mbits/sec         receiver  
  
iperf Done.

I know very little about DNS. I tried following wiki.archlinux.org/title/NetworkManager#dnsmasq to enable dnsmasq, but even after a full reboot, adding the /etc/NetworkManager/conf.d/dnsmasq.conf has not caused a change to resolv.conf.

# cat /etc/resolv.conf

# Generated by NetworkManager
search home
nameserver 192.168.1.254

mtr seems extremely useful and I’m now convinced the issue is in this pathing, as the problem is clearly with requesting and quickly receiving various content, rather than maintaining a download speed.

                                 My traceroute  [v0.95]
pigeon (192.168.1.203) -> google.com (142.250.178.14)           2024-08-05T16:43:03+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                Packets               Pings
 Host                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                   0.0%   117    0.8   0.8   0.6   1.2   0.1
 2. 172.16.17.220                              0.0%   117    7.6   7.5   7.0  14.6   0.7
 3. 141.hiper04.sheff.dial.plus.net.uk        93.0%   116   10.9   9.7   9.1  10.9   0.6
 4. 140.hiper04.sheff.dial.plus.net.uk         0.0%   116    9.7   9.9   9.3  11.9   0.3
 5. peer2-et-0-0-5.slough.ukcore.bt.net        0.0%   116   11.1  12.8  10.8  34.4   4.5
 6. 109.159.253.195                            0.0%   116   10.4  10.7  10.0  14.5   0.8
 7. 216.239.62.19                              1.7%   116   11.3  11.2  10.7  12.6   0.3
 8. 142.250.215.125                            0.0%   116   10.5  10.4   9.9  12.2   0.3
 9. lhr48s27-in-f14.1e100.net                  0.0%   116   10.4  10.5  10.0  11.2   0.2
                                 My traceroute  [v0.95]
pigeon (192.168.1.203) -> oeis.org (104.239.138.29)             2024-08-05T16:47:40+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                Packets               Pings
 Host                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                   0.0%    68    0.9   0.7   0.6   1.1   0.1
 2. 172.16.17.220                              0.0%    68    7.0   7.5   6.8   9.1   0.4
 3. 137.hiper04.sheff.dial.plus.net.uk        95.5%    68   11.8  12.0  11.8  12.3   0.3
 4. 136.hiper04.sheff.dial.plus.net.uk         0.0%    68   11.4  11.5  10.7  12.7   0.4
 5. core5-hu0-7-0-26.faraday.ukcore.bt.net     0.0%    68   11.0  11.5  10.7  12.5   0.5
 6. core6-hu0-7-0-35.faraday.ukcore.bt.net    41.2%    68   10.3  10.7  10.1  12.2   0.5
 7. 166-49-209-194.gia.bt.net                  0.0%    68   10.9  10.7  10.0  14.3   0.6
 8. (waiting for reply)
 9. ae4.cs3.lhr11.uk.eth.zayo.com             94.0%    68  121.0 121.3 121.0 121.7   0.3
10. ae5.cs1.lga5.us.eth.zayo.com              98.5%    67  117.4 117.4 117.4 117.4   0.0
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. ae6.er3.dfw2.us.zip.zayo.com               0.0%    67  120.5 121.0 120.2 123.1   0.6
15. 64.125.46.126.IPYX-172935-900-ZYO.zip.zay  0.0%    67  118.2 118.4 117.6 122.3   0.7
16. (waiting for reply)
17. cored-dcpe3.dfw1.rackspace.net             0.0%    67  120.7 121.0 120.4 122.6   0.5
18. core10-corec.dfw1.rackspace.net            0.0%    67  121.4 121.8 120.9 126.0   0.7
19. core9-aggr170a-7.dfw3.rackspace.net        0.0%    67  118.6 119.0 118.2 122.7   0.7
20. 104.239.138.29                             0.0%    67  117.6 118.0 117.2 120.0   0.5
                                 My traceroute  [v0.95]
pigeon (192.168.1.203) -> plus.net (212.159.8.2)                2024-08-05T16:53:16+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                Packets               Pings
 Host                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                   0.0%   142    0.8   0.8   0.6   1.2   0.1
 2. 172.16.17.220                              0.0%   142    6.7   6.6   6.2   8.4   0.3
 3. 141.hiper04.sheff.dial.plus.net.uk        98.6%   141    8.7   8.6   8.5   8.7   0.2
 4. 140.hiper04.sheff.dial.plus.net.uk         0.0%   141    9.0   9.0   8.3  11.2   0.4
 5. (waiting for reply)
 6. 195.166.129.176                            0.0%   141    9.5   9.8   9.4  11.3   0.3
 7. 84.93.224.48.plus.net                      0.7%   141   13.4  17.5  13.3 144.4  17.0
 8. 84.93.232.57.plus.net                      0.7%   141   14.8  18.8  14.7 217.3  21.3
 9. (waiting for reply)

I hope this info helps figure out what my next steps should be to solve the issue, but I’m completely new to network management and so am not sure how to interpret it myself.

Your local LAN connectivity is good, there is nothing wrong with your pc connectivity. As mtr shows clearly that your provider has overload problems on some of it’s hosts. I bet this varies with the daytime. You should test with mtr -T to get tcp results instead of plain ICMP. This might look different depending on what the provider does with routing. The thing is, for 98% loss in packets the provider deserves to have the face slammed on the table. The the most you can do is annoy them with repeated complaints until they maybe fix their issues. Phone them and tell them you pay for service, not for perhaps, maybe, lucky service. In addition, i would set a deadline and threaten to contact a lawyer.

Oh wow. I think we will probably just threaten to switch ISP at some point then. However, the ISP cannot be the majority of the issue here, given 1) other devices on the network don’t have the same problem & 2) this device has the same problem on other networks. So maybe this mtr output is barking up the wrong tree persay.
Here’s the output from google.com using mtr -T still on the ISP. I was going to try to get the output when connected to a mobile hotspot but now it appears that I cannot get a network connection on that, possibly something to do with the dnsmasq change I made? The only other PC on this network is Windows so it’d be harder to get commandline mtr running in the same way as here I think.

                                 My traceroute  [v0.95]
pigeon (192.168.1.203) -> google.com (142.250.200.14)          2024-08-05T19:03:43+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                               Packets               Pings
 Host                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                  0.0%    41    0.9   0.9   0.7   1.6   0.1
 2. (waiting for reply)
 3. 141.hiper04.sheff.dial.plus.net.uk       77.5%    41  4068. 1702.  10.4 4068. 1521.
 4. 140.hiper04.sheff.dial.plus.net.uk        0.0%    40   10.3  11.3  10.1  12.6   0.8
    136.hiper04.sheff.dial.plus.net.uk
 5. peer3-et0-1-7.redbus.ukcore.bt.net        0.0%    40   13.3  14.6  10.0  40.8   7.1
    peer3-et0-0-2.slough.ukcore.bt.net
    peer2-et4-0-5.slough.ukcore.bt.net
    peer3-et0-0-5.redbus.ukcore.bt.net
    peer7-et-4-0-5.telehouse.ukcore.bt.net
    peer8-et3-1-6.telehouse.ukcore.bt.net
    peer2-et-0-1-2.slough.ukcore.bt.net
    peer3-et-7-0-5.redbus.ukcore.bt.net
    peer2-et3-0-2.slough.ukcore.bt.net
 6. 195.99.126.247                            0.0%    40   11.1  12.7  10.5  25.7   2.4
    195.99.126.137
    109.159.253.75
    109.159.253.187
    109.159.253.185
    109.159.253.73
    peer2-xe3-1-3.telehouse.ukcore.bt.net
    109.159.253.189
 7. 216.239.48.217                            0.0%    40   13.1  12.6  11.1  13.5   0.6
    216.239.54.127
    209.85.249.187
    216.239.62.19
    216.239.42.41
    192.178.98.1
    216.239.49.185
    216.239.62.75
 8. 108.170.234.221                           0.0%    40   11.9  12.3  11.6  13.2   0.4
    108.170.234.231
 9. lhr48s29-in-f14.1e100.net                 0.0%    40   12.5  12.1  10.7  19.5   1.3

bbs.archlinux.org/viewtopic.php?id=275764
This post seems to reflect the problems I’m having connecting via my mobile hotspot, aside from dig @8.8.8.8 google.com and dig @1.1.1.1 google.com working. I’m not exactly sure though how to “set [my] laptop to use the dns servers the phone provides via dhcp” though.

Unfortunately, i have no idea what router you have, if it’s your’s or the ISP’s box, but usually if your ISP configures your router, and often this router has dns functionality. that means it receives requests and forwards them to the dns which is set by the provider. You find out which dns your isp runs by dig -t ANY hiper04.sheff.dial.plus.net.uk. That will tell you that your DNS is ns1.force9.net. Test this server by dig @ns1.force9.net www.google.de. From here that does not work as expected because that is a private, not a public DNS, so it answers only to requests from his own domain, not from me. I just get a reply without an ANSWER SECTION. Anyway, to test if dns gets blocked you use dig @dns-server request-name. You can get a list of public dns from googling. Try some of them, find out which work and which not. ip r tells you which ip address your router has, test if it runs a dns.

Your router probably has a DHCP running to configure all connected devices in your LAN with ip address, routes, dns and maybe other stuff too. That is the point where you configure which dns all hosts in your LAN utilize. Individually, your pc can use the dhcp configuration or you can override it. This is /etc/resolv.conv. It may start with Generated by NetworkManager, if that is the case editing this file is only temporary and gets overwritten soon. Often it contains a list of nameserver entries, but you must know, that they are requested sequentially, means the first is used and if it does not respond within timeout the resolver proceeds to the next one. That can take time, so you better make sure your first entry is a working one.

By the way, iperf can also be used with internet hosts, https://iperf3serverlist.net/
That is a better test because it saturates the line’s capacity to the limit.

If you have a dns issue, the beginning of a download or connection is delayed or not working at all, but once the stream or download started, the dns has no influence. You report low transmission rate, not a delayed transfer beginn, is that correct?

I see the opposite, which makes me think it is a dns issue. Any downloads get up to the 70Mbit/s that I’m expecting, but it’s the sending lots of requests, loading/refreshing pages, etc that’s slow.

So it seems like any public dns is getting through when connected to the ISP. When connected to the mobile hotspot instead, the dig -t ANY google.com times out with no servers could be reached, but any public dns does successfully get through i.e. dig @8.8.8.8 www.google.com (though dig @ns1.force9.net www.google.com of course does not since my mobile data provider is different). This implies to me that my PC isn’t trying to use any public dns to resolve requests, since when connected to the mobile data a normal web search times out.

I’ve tried to follow this to get NetworkManager to use a specific dns and ignore auto dns but nothing has seemed to change /etc/resolv.conf yet.

ok, got that wrong. You should really check DNS settings. Are you running a local dns cache?
Your “hotspot” means you have a laptop with built-in sim card and G3/G4 device? In case you operate that, does that mean you have two network devices in operation?

Have you IPv6 set up, and does your ISP provides real IPv6 or some IPv6 tunneling?
One dns issue is often that local LAN is configured hybrid (IPv4+IPv6) without having internet routes for IPv6. Recent OS prioritize IPV6 over IPv4 regardless of that fact. Result: first DNS request goes via IPv6, it times out, then it falls back to IPv4. Widespread issue that causes latency in initialization of connections. I have no IPv6 at all here, consequently i have completely disabled IPv6 on all LAN devices.

Not as far as I know. Is it worth switching from NetworkManager as I cannot seem to get it to affect my dns.

I mean connecting my laptop to a hotspot from my phone, using mobile data, since that’s the only alternate network provider I have access to at the moment. I was hoping to test mtr on it since it would bypass the ISP issues we found, but my computer seems unable to resolve any requests when connected solely to it, aside from specifically dig @public-dns request.

My ISP shows Hub IPv6 status: Enabled but also IPv6 network status: Disabled and DNS: IPv4 only. I have done nothing on my end to disable IPv6, and on all my EOS settings it shows Method: Automatic for both IPv4 and 6.