Painfully slow ethernet after some use

b0ss_ · 2024-03-18 12:51:12

Hi everyone.

I've been having this issue lately that makes my ethernet slow as a turtle.

Initially, my ethernet connection works as expected. 600+mbps downloads and uploads. This is the expected behaviour. But after some hours of use, speed goes down to an amazing >1MBPS downloads and uploads. Although, and I saw this on the mainline kernel, only download speeds died down, but uploads stayed at >500 mbps. In the lts kernel, that's not the case.

Thought this was weird, so I booted into an arch live USB environment, downloaded speedtest-cli and ran some tests.

At first, I thought it was an issue with some kernel related updates, and I say that because I booted into linux-lts and the issue was solved. But after some hours, the issue comes back.

I tried both r8168 and r8169 kernel drivers. Both presented the same issues, but after booting into linux-lts, r8169 was the only available driver (perhaps because I blacklisted r8168, or maybe because I don't have the lts driver). Also tried this command: "sudo sysctl net.ipv4.tcp_ecn=0". Didn't do anything.

I'm using NetworkManager + wpa_supplicant, although I use "nmtui" to configure my connections.

$ sudo journalctl -u NetworkManager | nc termbin.com 9999

https://termbin.com/rsdu

$ sudo journalctl -b | nc termbin.com 9999

https://termbin.com/nuc9

$ sudo dmesg | grep r8169 
[    4.423014] r8169 0000:09:00.0 eth0: RTL8168ep/8111ep, 00:d8:61:8d:0d:b3, XID 502, IRQ 45
[    4.423021] r8169 0000:09:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    4.423023] r8169 0000:09:00.0 eth0: DASH disabled
[    5.016718] r8169 0000:09:00.0 eth0: rtl_ep_ocp_read_cond == 0 (loop: 30, delay: 10000).
[    8.303530] r8169 0000:09:00.0 enp9s0f0: renamed from eth0
[   40.400015] Generic FE-GE Realtek PHY r8169-0-900:00: attached PHY driver (mii_bus:phy_addr=r8169-0-900:00, irq=MAC)
[   40.993877] r8169 0000:09:00.0 enp9s0f0: rtl_ep_ocp_read_cond == 0 (loop: 30, delay: 10000).
[   41.113485] r8169 0000:09:00.0 enp9s0f0: Link is Down
[   43.408897] r8169 0000:09:00.0 enp9s0f0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 6191.554595] r8169 0000:09:00.0 enp9s0f0: Link is Down
[ 6194.093076] Generic FE-GE Realtek PHY r8169-0-900:00: attached PHY driver (mii_bus:phy_addr=r8169-0-900:00, irq=MAC)
[ 6194.663121] r8169 0000:09:00.0 enp9s0f0: rtl_ep_ocp_read_cond == 0 (loop: 30, delay: 10000).
[ 6194.779887] r8169 0000:09:00.0 enp9s0f0: Link is Down
[ 6197.088619] r8169 0000:09:00.0 enp9s0f0: Link is Up - 1Gbps/Full - flow control rx/tx

$ sudo sysctl -a |& grep ipv4.tcp
[sudo] contraseña para b0ss: 
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_adv_win_scale = 1
net.ipv4.tcp_allowed_congestion_control = reno cubic
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_autocorking = 1
net.ipv4.tcp_available_congestion_control = reno cubic
net.ipv4.tcp_available_ulp = espintcp mptcp
net.ipv4.tcp_base_mss = 1024
net.ipv4.tcp_challenge_ack_limit = 2147483647
net.ipv4.tcp_child_ehash_entries = 0
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_comp_sack_slack_ns = 100000
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_early_demux = 1
net.ipv4.tcp_early_retrans = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_ecn_fallback = 1
net.ipv4.tcp_ehash_entries = 262144
net.ipv4.tcp_fack = 0
net.ipv4.tcp_fastopen = 1
net.ipv4.tcp_fastopen_blackhole_timeout_sec = 0
net.ipv4.tcp_fastopen_key = 00000000-00000000-00000000-00000000
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_frto = 2
net.ipv4.tcp_fwmark_accept = 0
net.ipv4.tcp_invalid_ratelimit = 500
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_l3mdev_accept = 0
net.ipv4.tcp_limit_output_bytes = 1048576
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_max_orphans = 131072
net.ipv4.tcp_max_reordering = 300
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_max_tw_buckets = 131072
net.ipv4.tcp_mem = 382257	509678	764514
net.ipv4.tcp_migrate_req = 0
net.ipv4.tcp_min_rtt_wlen = 300
net.ipv4.tcp_min_snd_mss = 48
net.ipv4.tcp_min_tso_segs = 2
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_mtu_probe_floor = 48
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_no_ssthresh_metrics_save = 1
net.ipv4.tcp_notsent_lowat = 4294967295
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_pacing_ca_ratio = 120
net.ipv4.tcp_pacing_ss_ratio = 200
net.ipv4.tcp_plb_cong_thresh = 128
net.ipv4.tcp_plb_enabled = 0
net.ipv4.tcp_plb_idle_rehash_rounds = 3
net.ipv4.tcp_plb_rehash_rounds = 12
net.ipv4.tcp_plb_suspend_rto_sec = 60
net.ipv4.tcp_probe_interval = 600
net.ipv4.tcp_probe_threshold = 8
net.ipv4.tcp_recovery = 1
net.ipv4.tcp_reflect_tos = 0
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_rmem = 4096	131072	6291456
net.ipv4.tcp_sack = 1
net.ipv4.tcp_shrink_window = 0
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_syn_linear_timeouts = 4
net.ipv4.tcp_syn_retries = 6
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tso_rtt_log = 9
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_tw_reuse = 2
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_wmem = 4096	16384	4194304
net.ipv4.tcp_workaround_signed_windows = 0

$ sudo lshw -c network
  *-network                 
       description: Ethernet interface
       product: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus information: pci@0000:09:00.0
       logical name: enp9s0f0
       version: 0e
       serial: 00:d8:61:8d:0d:b3
       size: 1Gbit/s
       capacity: 1Gbit/s
       lenght: 64 bits
       clock: 33MHz
       cappabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.6.22-1-lts duplex=full ip=192.168.1.168 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:25 ioport:ec00(tamaño=256) memoria:fe618000-fe618fff memoria:fe610000-fe613fff

$ lspci -k | grep -4 Ethernet
(SNIP)
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 0e)
	Subsystem: Lenovo RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
	Kernel driver in use: r8169
	Kernel modules: r8169
(/SNIP)

$ uname -a
Linux home 6.6.22-1-lts #1 SMP PREEMPT_DYNAMIC Sat, 16 Mar 2024 06:20:33 +0000 x86_64 GNU/Linux

$ sudo inxi -FxxxZ
System:
  Host: home Kernel: 6.6.22-1-lts arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.1 clocksource: tsc
  Desktop: Hyprland v: N/A with: waybar dm: N/A Distro: Arch Linux
Machine:
  Type: Desktop System: LENOVO product: 10MBS02D00 v: Lenovo Product
    serial: MJ07503R Chassis: type: 3 serial: INVALID
  Mobo: LENOVO model: 3141 v: SDK0K17763 WIN 1801944579810 serial: N/A
    part-nu: LENOVO_MT_10MB_BU_Lenovo_FM_Lenovo Product
    uuid: 8dcbdc00-ee88-11e7-a19b-d4cece5f6100 UEFI: LENOVO v: M25KT5AA
    date: 08/31/2020
CPU:
  Info: quad core model: AMD Ryzen 3 PRO 2200G with Radeon Vega Graphics
    bits: 64 type: MCP smt: <unsupported> arch: Zen rev: 0 cache: L1: 384 KiB
    L2: 2 MiB L3: 4 MiB
  Speed (MHz): avg: 2075 high: 3500 min/max: 1600/3500 boost: enabled cores:
    1: 1600 2: 1600 3: 3500 4: 1600 bogomips: 27956
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
  Device-1: AMD Polaris 20 XL [Radeon RX 580 2048SP] driver: amdgpu v: kernel
    arch: GCN-4 pcie: speed: 8 GT/s lanes: 8 ports: active: HDMI-A-1
    empty: DP-1,DVI-D-1 bus-ID: 01:00.0 chip-ID: 1002:6fdf class-ID: 0300
    temp: 31.0 C
  Display: server: Xwayland v: 23.2.4 compositor: Hyprland driver: X:
    loaded: modesetting alternate: fbdev,vesa gpu: amdgpu display-ID: :0
  Monitor-1: HDMI-A-1 model: HDMI serial: 0000000000001 res: 1920x1080
    dpi: 92 size: 530x280mm (20.87x11.02") diag: 599mm (23.6") modes:
    max: 1920x1080 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast surfaceless: drv: radeonsi inactive: gbm,wayland,x11
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: mesa v: 24.0.3-arch1.1
    note: incomplete (EGL sourced) renderer: AMD Radeon RX 580 2048SP (radeonsi
    polaris10 LLVM 17.0.6 DRM 3.54 6.6.22-1-lts), llvmpipe (LLVM 17.0.6 256
    bits)
  API: Vulkan Message: No Vulkan data available.
Audio:
  Device-1: AMD Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 8 bus-ID: 01:00.1
    chip-ID: 1002:aaf0 class-ID: 0403
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor driver: snd_pci_acp3x
    v: kernel pcie: speed: 8 GT/s lanes: 16 bus-ID: 0a:00.5 chip-ID: 1022:15e2
    class-ID: 0480
  Device-3: AMD Family 17h/19h HD Audio vendor: Lenovo driver: snd_hda_intel
    v: kernel pcie: speed: 8 GT/s lanes: 16 bus-ID: 0a:00.6 chip-ID: 1022:15e3
    class-ID: 0403
  API: ALSA v: k6.6.22-1-lts status: kernel-api
  Server-1: sndiod v: N/A status: off
  Server-2: PipeWire v: 1.0.4 status: n/a (root, process) with:
    1: pipewire-pulse status: active 2: wireplumber status: active
    3: pipewire-alsa type: plugin 4: pw-jack type: plugin
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: Lenovo RTL8111/8168/8411 driver: r8169 v: kernel pcie:
    speed: 2.5 GT/s lanes: 1 port: ec00 bus-ID: 09:00.0 chip-ID: 10ec:8168
    class-ID: 0200
  IF: enp9s0f0 state: up speed: 1000 Mbps duplex: full
    mac: 00:d8:61:8d:0d:b3
Bluetooth:
  Device-1: SINO WEALTH Bluetooth Keyboard driver: hid-generic,usbhid
    type: USB rev: 1.1 speed: 12 Mb/s lanes: 1 bus-ID: 4-3:2 chip-ID: 258a:00e1
    class-ID: 0300
  Device-2: Qualcomm Atheros QCA61x4 Bluetooth 4.0 driver: btusb v: 0.8
    type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 bus-ID: 4-4:3 chip-ID: 0cf3:e300
    class-ID: e001
  Report: ID: hci0 rfk-id: 0 state: up address: N/A
Drives:
  Local Storage: total: 1.13 TiB used: 789.49 GiB (68.3%)
  ID-1: /dev/sda vendor: Gigabyte model: GP-GSTFS31240GNTD size: 223.57 GiB
    speed: 6.0 Gb/s tech: SSD serial: SN234008923716 fw-rev: 61.5 scheme: GPT
  ID-2: /dev/sdb vendor: Western Digital model: WD10EZEX-60WN4A0
    size: 931.51 GiB speed: 6.0 Gb/s tech: HDD rpm: 7200 serial: WD-WCC6Y6TDFJ46
    fw-rev: 1A01 scheme: GPT
Partition:
  ID-1: / size: 218.51 GiB used: 28.25 GiB (12.9%) fs: ext4 dev: /dev/sda2
  ID-2: /boot size: 511 MiB used: 345.1 MiB (67.5%) fs: vfat dev: /dev/sda1
  ID-3: /home size: 915.82 GiB used: 760.9 GiB (83.1%) fs: ext4
    dev: /dev/sdb1
Swap:
  ID-1: swap-1 type: zram size: 4 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 39.8 C mobo: N/A gpu: amdgpu temp: 31.0 C
  Fan Speeds (rpm): N/A gpu: amdgpu fan: 1853
Info:
  Memory: total: 32 GiB available: 31.28 GiB used: 3.85 GiB (12.3%)
  Processes: 237 Power: uptime: 2h 1m states: freeze,mem,disk suspend: deep
    wakeups: 0 hibernate: platform Init: systemd v: 255 default: graphical
  Packages: pm: pacman pkgs: 1156 Compilers: clang: 17.0.6 gcc: 13.2.1
    Shell: Sudo (sudo) v: 1.9.15p5 default: Bash v: 5.2.26 running-in: kitty
    inxi: 3.3.33

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=90b89d1d-e013-4458-96bf-c105d0fec91b rw zswap.enabled=0 rootfstype=ext4 loglevel=9 quiet pcie_aspm=1 pcie_aspm.policy=performance amdgpu.aspm=1

$ 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: enp9s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:d8:61:8d:0d:b3 brd ff:ff:ff:ff:ff:ff

If any other info is needed, just let me know.
Thanks.

Last edited by b0ss_ (2024-03-22 19:10:37)

seth · 2024-03-18 14:48:33

Did you test the throughput against a different LAN host to make sure it's not the WAN?

Does changing or reloading the driver fix the speed issues?
Does re-plugging the cable?

but after booting into linux-lts, r8169 was the only available driver

https://archlinux.org/packages/extra/x86_64/r8168-lts/

I'm using NetworkManager + wpa_supplicant

You#re starting iwd and there's no wlan chip in that journal?

----
OT: You're btw. aware that there's an impressive amout of Hyprland and waybar segfualts?

b0ss_ · 2024-03-18 15:06:15

seth wrote:

Did you test the throughput against a different LAN host to make sure it's not the WAN?

Yeah, through my phone I get around 200~mbps. Using USB tethering, my PC gets blazing fast internet. Also, hi Seth! Good to see you mate.

Does changing or reloading the driver fix the speed issues?
Does re-plugging the cable?

Tried both, neither worked. I can't really tell if it's a physical layer issue, since the ethernet card does work properly under an live arch environment.

ou#re starting iwd and there's no wlan chip in that journal?

Yeah I'm stupid sorry lol. Disabled and stopped the iwd service. The "wpa_supplicant" was never active, and I think I installed it previously trying to revive the WiFI card I had that was destroyed ~because I couldn't get the cable out from the old case and totally broke it~ for unknown reasons. Nevertheless, the problem is still going. I will try the r8168-lts driver though, I'll come back with results.

OT: You're btw. aware that there's an impressive amout of Hyprland and waybar segfualts?

Yeah. For some reason, when I kill the hyprland session, it segfaults. Don't ask me why lol.

EDIT: tried the r8168-lts driver. No luck. Although for some reason, it "improves" upload speeds from a blazingly fast 1.79 mbps to a ginormous 6.24 mbps. Downloads are still between the range of 0.1 and 0.25mbps.

Last edited by b0ss_ (2024-03-18 15:11:05)

seth · 2024-03-18 15:18:35

since the ethernet card does work properly under an live arch environment

So this

Thought this was weird, so I booted into an arch live USB environment, downloaded speedtest-cli and ran some tests.

was meant to say "… and the network worked fine"?
And also

Using USB tethering, my PC gets blazing fast internet.

Something tells me that we're not done w/ the ASPM situation…
Have you tried pcie_aspm=off and then the network performance on the console?

b0ss_ · 2024-03-18 15:23:41

seth wrote:

since the ethernet card does work properly under an live arch environment
So this
Thought this was weird, so I booted into an arch live USB environment, downloaded speedtest-cli and ran some tests.
was meant to say "… and the network worked fine"?

Yes! Sorry I'm working as we speak and I might omit some words. Forgive me

Something tells me that we're not done w/ the ASPM situation…
Have you tried pcie_aspm=off and then the network performance on the console?

God fucking damn it. Not this again. It's been working properly man, it's a very very recent issue. I will try it, but for fucks sake, why is ASPM so god damn important... (rhetorical question, no answer needed).

I'll try it out. WML

EDIT: Tried it. I hate the fact that you might be right. With "pcie_aspm=off" it works fine. Ran a speedtest and I got over 700+mbps. Of course, I had to start the system with "acpi=off" for reasons that we already know.

I booted with my genius™ command line parameters and... for some reason the card is alive again? It seems, well, unstable. This happened to me before, and it might've had to do with the live environment telling the ethernet controller to wake up or something like that, taking it out from its eternal slumber.

As we speak, I'm using the r8169 driver on the mainline kernel. I'll send some journals just to be sure.

$ sudo journalctl -b

https://termbin.com/ygti

$ sudo dmesg

https://termbin.com/56ab

If you need something else, let me know.

Last edited by b0ss_ (2024-03-18 15:34:03)

seth · 2024-03-18 18:08:14

for some reason the card is alive again? It seems, well, unstable. This happened to me before, and it might've had to do with the live environment telling the ethernet controller to wake up

How reliable is this?
Also: does this mean once the NIC gets into SloMo, it's stuck there even across reboots? Until either you boot a different source (usb) or pcie_aspm/acpi=off?

Can you prevent it from getting slow by throwing it a life-line "ping google.com"?
Any idea what triggers the SloMo? Just time or maybe an S3 (suspend to RAM)?

b0ss_ · 2024-03-18 18:30:35

seth wrote:

for some reason the card is alive again? It seems, well, unstable. This happened to me before, and it might've had to do with the live environment telling the ethernet controller to wake up
How reliable is this?
Also: does this mean once the NIC gets into SloMo, it's stuck there even across reboots? Until either you boot a different source (usb) or pcie_aspm/acpi=off?

It's "reliable". It lasts for a few hours, but then it goes into turtle mode. And yes, this persists after reboots. And also yes, it seems that I have to boot with pcie_aspm=off + acpi=off to make it wake up. I've been trying to find ways in which I can deny the NIC the ability to sleep, due to the fact that it seems to be related to power issues., as you correctly mentioned. I tend to leave my PC on during the night, and maybe it gets to some kind of sleep mode. I find this to be esoteric at best, since I haven't been able to find any documentation related to the r8168-9 drivers. Nor any kernel parameters, for that matter.

Can you prevent it from getting slow by throwing it a life-line "ping google.com"?
Any idea what triggers the SloMo? Just time or maybe an S3 (suspend to RAM)?

This PC can't suspend into ram. Or rather I haven't set that up, not that I care really. But no, I haven't tried the ping method yet. It might've to do with the aspm configuration, but it doesn't really make much sense. My mobo has ASPM support, it is enabled in the BIOS, it's also enabled on the GRUB cmdline. Although, I remember you mentioning the fact that "pcie_aspm=1" isn't really a valid parameter, and since it fulfilled the job of fixing the GPU issue I had recently, I haven't changed it. I will try to change it and see what happens. Don't really think it'll do much, to be honest.

seth · 2024-03-18 18:39:17

cat /sys/power/mem_sleep
systemctl suspend

I also speculated that the parser is probably tolerant enough to take "1" as "on" here.

I highly doubt that the NIC does anything because of daytime, though

I tend to leave my PC on during the night

Greta does not approve

Rather try to keep the NIC busy, that'll have more impact on it taking a nap than whether it's past teletubbie hour.

b0ss_ · 2024-03-18 19:40:51

seth wrote:

cat /sys/power/mem_sleep
systemctl suspend

$ cat /sys/power/mem_sleep
s2idle [deep]

$ systemctl suspend

Well yeah, manually it will go to suspension, but what I meant is that I do not actively use it nor I have it binded to any key or combination of keys. At most, suspension is achieved when I close Hyprland and go back to ly.

I also speculated that the parser is probably tolerant enough to take "1" as "on" here.

True.

I highly doubt that the NIC does anything because of daytime, though

I mean, during daytime it does stuff?

I tend to leave my PC on during the night
Greta does not approve
Rather try to keep the NIC busy, that'll have more impact on it taking a nap than whether it's past teletubbie hour.

Yeah yeah you're right. I'll probably have to create a service that runs a ping to Google 24/7, or at least during nighttime.

If the card goes to turtle mode again, I'll post in this thread. Because as we speak, it's been working as expected. Nevertheless, it will fail, I assure you that.

seth · 2024-03-18 22:07:13

You can just keep ping running in a background terminal, you can also moderate the frequency and skip DNS

ping -ni5 google.com

b0ss_ · 2024-03-22 14:33:04

It happened again.

$ speedtest 
Retrieving speedtest.net configuration...
Testing from [REDACTED]...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by [REDACTED] 10.719 ms
Testing download speed................................................................................
Download: 0.50 Mbit/s
Testing upload speed......................................................................................................
Upload: 624.64 Mbit/s

Weird, right? Turtle downloads, but rabbit uploads. I've had this happen to me before. dmesg doesn't show anything either:

$ sudo dmesg | grep r8169
[    5.122413] r8169 0000:09:00.0 eth0: RTL8168ep/8111ep, 00:d8:61:8d:0d:b3, XID 502, IRQ 45
[    5.122423] r8169 0000:09:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    5.122425] r8169 0000:09:00.0 eth0: DASH disabled
[    5.721191] r8169 0000:09:00.0 eth0: rtl_ep_ocp_read_cond == 0 (loop: 30, delay: 10000).
[    9.557202] r8169 0000:09:00.0 enp9s0f0: renamed from eth0
[   45.933356] Generic FE-GE Realtek PHY r8169-0-900:00: attached PHY driver (mii_bus:phy_addr=r8169-0-900:00, irq=MAC)
[   46.516766] r8169 0000:09:00.0 enp9s0f0: rtl_ep_ocp_read_cond == 0 (loop: 30, delay: 10000).
[   46.636835] r8169 0000:09:00.0 enp9s0f0: Link is Down
[   48.910049] r8169 0000:09:00.0 enp9s0f0: Link is Up - 1Gbps/Full - flow control rx/tx

Since enabling and disabling pcie_aspm usually does a thing or two with the ethernet controller, I'll be trying to use the following kernel parameters on the r8168 module:

r8168.aspm=0 r8168.dynamic_aspm=0

Might do the trick. Might not. Will report back with news.

b0ss_ · 2024-03-22 14:49:08

Tried it. Did not work.

What I tried afterwards:

r8168.aspm=1 r8168.dynamic_aspm=1

No luck.

r8168.aspm=1 r8168.dynamic_aspm=1 r8168.dynamic_aspm_packet_threshold=0 r8168.disable_wol_support=1

Nothing. Card is still dead.

I've also discarded a sleep mode issue, because I was actively using the ethernet controller and it suddenly started to act like a turtle.

b0ss_ · 2024-03-22 14:54:52

im FUCKING stupid. I did a grub-mkconfig INTO THE GOD DAMN /etc/default/grub INSTEAD OF THE /BOOT/GRUB/GRUB.CFG FILE.

any way to uhmm regen this file?

seth · 2024-03-22 14:57:52

You can get the default from https://gitlab.archlinux.org/archlinux/ … type=heads
Your previous version is gonna be tough to impossible (assuming you've rebooted already)

Edit: since there's no uplink issue I doubt it's powemanagement related.

Last edited by seth (2024-03-22 14:58:36)

Scimmia · 2024-03-22 14:58:20

https://gitlab.archlinux.org/archlinux/ … type=heads

You'll have to make whatever changes you had made previously, usually just to the cmdline parts.

b0ss_ · 2024-03-22 15:13:46

thanks guys, but I actually just pacman -Rsd grub, pacman -S grub, reinstalled manually and fixed the cmdline params. Ignoring my fuckup, the ethernet card is still in slowmo.

seth wrote:

Edit: since there's no uplink issue I doubt it's powemanagement related.

Indeed. I know that if I disable pcie_aspm and boot with acpi=off, the ethernet will come back to its original glory, but I don't want to do that every time this happens.

seth · 2024-03-22 15:47:49

Have you tried keeping your aspm hack and still just lying to the ACPI?

acpi_osi=! acpi_osi="Windows 2015"

https://learn.microsoft.com/en-us/windo … inacpi-osi

(Can't be the tcp rx buffers either if the slow mode survives reboots…)

b0ss_ · 2024-03-22 16:15:44

seth wrote:

Have you tried keeping your aspm hack and still just lying to the ACPI?
acpi_osi=! acpi_osi="Windows 2015"
https://learn.microsoft.com/en-us/windo … inacpi-osi
(Can't be the tcp rx buffers either if the slow mode survives reboots…)

I remember using this parameters before, when I had issues with the GPU. I will try 'em out again, will report back with news.

b0ss_ · 2024-03-22 16:24:18

Nah, it doesn't work. My cmdline:

BOOT_IMAGE=/vmlinuz-linux root=UUID=90b89d1d-e013-4458-96bf-c105d0fec91b rw loglevel=3 quiet pcie_aspm=1 amdgpu.aspm=1 pcie_aspm.policy=performance snd_usb_audio.implict_fb=1 snd_usb_audio.lowlatency=0 r8168.aspm=1 r8168.dynamic_aspm=0 r8168.debug=16 r8168.disable_wol_support=1 usbcore.autosuspend=-1 iacpi_osi=! "acpi_osi=Windows 2015"

What I still don't understand is that if the card was in slowmo, one would think that both download and upload speeds would be halted, but only download speeds seem to be affected. Because as I previouly showed, uploads are on the 600-700mpbs~ range. I just don't understand why.

EDIT: I inserted a "i" by mistake in the cmdline. will try again!

Last edited by b0ss_ (2024-03-22 16:26:04)

b0ss_ · 2024-03-22 16:34:18

ok, my machine didn't like being called windows, bc it didn't boot with those parameters. "loglevel=9" doesn't show anything useful either. I'll try without the "acpi_osi=!" flag.

EDIT: OK! it works!

my rationale for not using the "acpi_osi=!" flag is from this forum post:

Note on acpi_osi=!
This argument disables all vendor strings that maybe present. It should only be used if one of the above OSI strings does not work on its own. If you use it when it is not needed, you maybe able to boot without any acpi errors, but your touchpad or wifi will not work. It also must be used in combination one of the above OSI strings.

Using "acpi_osi='Windows 2015'" works well. thanks again, @seth!

ps: if it does go into slowmo again, I'll post it here lol. wml

Last edited by b0ss_ (2024-03-22 16:37:58)

b0ss_ · 2024-03-22 19:10:16

SIKE! It's dead again. It happened again, went into slowmo, even with the acpi_osi flags set. I was doing some critical tasks (cs2) so I immediately used the old trick of acpi=off pcie_aspm=0.

But it was slow again, don't really know why at this point.

Last edited by b0ss_ (2024-03-22 19:11:21)

seth · 2024-03-22 20:19:42

W/o the clearing flag acpi_osi is probably inert.
What parameters does

modinfo r8168

actually offer you?

Because only one direction is affected, does it hel pto disable TSO:

sudo ethtool -K enp9s0f0 tso off

(nb. that this is transient and will not survive a reboot)

Curveball: what is you limit the speed to 100M via ethtool

sudo ethtool -s enp9s0f0 autoneg off
sudo ethtool -s enp9s0f0 speed 100

(dto.)

You can probably try both and ifffff it stabilizes the link, see which one is more important.

b0ss_ · 2024-03-22 21:38:14

seth wrote:

W/o the clearing flag acpi_osi is probably inert.
What parameters does
modinfo r8168
actually offer you?

$ modinfo r8168
filename:       /lib/modules/6.8.1-arch1-1/extramodules/r8168.ko.xz
version:        8.052.01-NAPI
firmware:       rtl_nic/rtl8168fp-4.fw
firmware:       rtl_nic/rtl8168fp-3.fw
firmware:       rtl_nic/rtl8168h-4.fw
firmware:       rtl_nic/rtl8168h-3.fw
firmware:       rtl_nic/rtl8168h-2.fw
firmware:       rtl_nic/rtl8168h-1.fw
firmware:       rtl_nic/rtl8168ep-3.fw
firmware:       rtl_nic/rtl8168ep-2.fw
firmware:       rtl_nic/rtl8168ep-1.fw
firmware:       rtl_nic/rtl8168g-3.fw
firmware:       rtl_nic/rtl8168g-2.fw
firmware:       rtl_nic/rtl8411-2.fw
firmware:       rtl_nic/rtl8411-1.fw
firmware:       rtl_nic/rtl8168f-2.fw
firmware:       rtl_nic/rtl8168f-1.fw
firmware:       rtl_nic/rtl8168e-4.fw
firmware:       rtl_nic/rtl8168e-3.fw
firmware:       rtl_nic/rtl8168e-2.fw
firmware:       rtl_nic/rtl8168e-1.fw
firmware:       rtl_nic/rtl8168d-2.fw
firmware:       rtl_nic/rtl8168d-1.fw
license:        GPL
description:    RealTek RTL-8168 Gigabit Ethernet driver
author:         Realtek and the Linux r8168 crew <netdev@vger.kernel.org>
srcversion:     10CC0A50F6726DF579A4E85
alias:          pci:v00001186d00004300sv00001186sd00004B10bc*sc*i*
alias:          pci:v000010ECd00002600sv*sd*bc*sc*i*
alias:          pci:v000010ECd00002502sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008161sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008168sv*sd*bc*sc*i*
depends:        
retpoline:      Y
name:           r8168
vermagic:       6.8.1-arch1-1 SMP preempt mod_unload 
parm:           speed_mode:force phy operation. Deprecated by ethtool (8). (uint)
parm:           duplex_mode:force phy operation. Deprecated by ethtool (8). (uint)
parm:           autoneg_mode:force phy operation. Deprecated by ethtool (8). (uint)
parm:           advertising_mode:force phy operation. Deprecated by ethtool (8). (uint)
parm:           dynamic_aspm:int
parm:           aspm:Enable ASPM. (int)
parm:           s5wol:Enable Shutdown Wake On Lan. (int)
parm:           s5_keep_curr_mac:Enable Shutdown Keep Current MAC Address. (int)
parm:           use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm:           timer_count:Timer Interrupt Interval. (int)
parm:           eee_enable:Enable Energy Efficient Ethernet. (int)
parm:           hwoptimize:Enable HW optimization function. (ulong)
parm:           s0_magic_packet:Enable S0 Magic Packet. (int)
parm:           dynamic_aspm_packet_threshold:Dynamic ASPM packet threshold. (int)
parm:           disable_wol_support:Disable PM support. (int)
parm:           debug:Debug verbosity level (0=none, ..., 16=all) (int)

Something interesting I've see is that for some reason, the r8168 module taints the kernel:

$ sudo dmesg | grep r8168
[    7.392709] r8168: loading out-of-tree module taints kernel.
[    7.392722] r8168: module verification failed: signature and/or required key missing - tainting kernel

This doesn't happen with the r8169 module, but that one has no parameter configurations, at least on my system. Btw, those are the entire dmesg logs for the r8168 module. There's nothing else. Not even with the "r8168.debug=16" flag set.

Because only one direction is affected, does it hel pto disable TSO:
sudo ethtool -K enp9s0f0 tso off
(nb. that this is transient and will not survive a reboot)
Curveball: what is you limit the speed to 100M via ethtool
sudo ethtool -s enp9s0f0 autoneg off
sudo ethtool -s enp9s0f0 speed 100
(dto.)
You can probably try both and ifffff it stabilizes the link, see which one is more important.

I will, whenever I get the slowmo mode again. Although limiting internet speeds would be less than optimal. Will try whenever it happens again. thanks again, seth!

EDIT: forgot to mention: I don't really know what I did, but now my microphone is broken again. First reported at here, so I'll have to reopen it.

Last edited by b0ss_ (2024-03-22 21:47:21)

seth · 2024-03-22 21:44:09

No, the plan is to do that *ahead* to prevent this from happening. After the fact will not help for sure (ifff this is related)
At least disable TSO unconditionally (since re-plugging the cable doesn't help, but the aspm/acpi dance does the speed limit to prevent over-aggressive downshifts from the link partner is a far reach anyway)

You could also try "eee_enable" but b/c of the persistent state and the uplink performance I still don't thik it's power management related.

b0ss_ · 2024-03-22 21:55:06

seth wrote:

No, the plan is to do that *ahead* to prevent this from happening. After the fact will not help for sure (ifff this is related)
At least disable TSO unconditionally (since re-plugging the cable doesn't help, but the aspm/acpi dance does the speed limit to prevent over-aggressive downshifts from the link partner is a far reach anyway)

Will do! Should I create a service file to make that fix permanent at some point? :3

You could also try "eee_enable" but b/c of the persistent state and the uplink performance I still don't thik it's power management related.

I thought of trying that, but I've started to realize this mobo doesn't like to manage power efficiently on Linux lol. Nevertheless, I'll add it to my cmdline. ty

Arch Linux

#1 2024-03-18 12:51:12

Painfully slow ethernet after some use

#2 2024-03-18 14:48:33

Re: Painfully slow ethernet after some use

#3 2024-03-18 15:06:15

Re: Painfully slow ethernet after some use

#4 2024-03-18 15:18:35

Re: Painfully slow ethernet after some use

#5 2024-03-18 15:23:41

Re: Painfully slow ethernet after some use

#6 2024-03-18 18:08:14

Re: Painfully slow ethernet after some use

#7 2024-03-18 18:30:35

Re: Painfully slow ethernet after some use

#8 2024-03-18 18:39:17

Re: Painfully slow ethernet after some use

#9 2024-03-18 19:40:51

Re: Painfully slow ethernet after some use

#10 2024-03-18 22:07:13

Re: Painfully slow ethernet after some use

#11 2024-03-22 14:33:04

Re: Painfully slow ethernet after some use

#12 2024-03-22 14:49:08

Re: Painfully slow ethernet after some use

#13 2024-03-22 14:54:52

Re: Painfully slow ethernet after some use

#14 2024-03-22 14:57:52

Re: Painfully slow ethernet after some use

#15 2024-03-22 14:58:20

Re: Painfully slow ethernet after some use

#16 2024-03-22 15:13:46

Re: Painfully slow ethernet after some use

#17 2024-03-22 15:47:49

Re: Painfully slow ethernet after some use

#18 2024-03-22 16:15:44

Re: Painfully slow ethernet after some use

#19 2024-03-22 16:24:18

Re: Painfully slow ethernet after some use

#20 2024-03-22 16:34:18

Re: Painfully slow ethernet after some use

#21 2024-03-22 19:10:16

Re: Painfully slow ethernet after some use

#22 2024-03-22 20:19:42

Re: Painfully slow ethernet after some use

#23 2024-03-22 21:38:14

Re: Painfully slow ethernet after some use

#24 2024-03-22 21:44:09

Re: Painfully slow ethernet after some use

#25 2024-03-22 21:55:06

Re: Painfully slow ethernet after some use

Board footer