Ubuntu
linux package

Slow download speed kubuntu 23.04 starting from kernel 6.2.0-25

Bug #2028999 reported by Giovanni Panozzo on 2023-07-29

This bug affects 4 people

Affects		Status	Importance	Assigned to	Milestone
	linux (Ubuntu)	Confirmed	Undecided	Unassigned

Bug Description

After upgrading kernel to linux-image-6.2.0-25-generic (or -26), I experience slow download speed (20-30Mbps instead of the expected 500Mbps-1Gbps). This happens with firefox, chrome, chromium and wget. Upload speeds are ok.

Downloads in LAN seems not to be affected. Only from the Internet (i.e.: speedtest.net with firefox/chrome/chromium or some big ISO files downloads).

When booting with older kernel, i.e. 6.2.0-24, the problem disappear.

My network card is a Realtek, see attached lspci output, and is using r8169 module.
PC is a Dell Optiplex 3080

/proc/version_signature: Ubuntu 6.2.0-26.26-generic 6.2.13
lspci output is attached

Tags:

Revision history for this message

Giovanni Panozzo (giox069) wrote on 2023-07-29:

lspci-vnvn.log Edit (35.8 KiB, text/plain)

Giovanni Panozzo (giox069) on 2023-08-03

tags:

added: r8169

Revision history for this message

Launchpad Janitor (janitor) wrote on 2023-08-08:

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux (Ubuntu):
status:	New → Confirmed

Revision history for this message

Johannes Hessellund (osos) wrote on 2023-08-08:

I can confirm this bug. Using Linux Mint here. Noticed decrease after upgrading to latest. Reverting to kernel 5.19.0-43-generic solved it.

Download speed with kernel 5.19.0-43 = 980mbit/s
Download speed with kernel 6.2.0-25 = 50-70mbit/s

Upload speed both = 980mbit/s

lspci:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

Revision history for this message

Mike Ferreira (mafoelffen) wrote on 2023-08-22:

Re: This bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2031240
Seems to be a duplicate of this one, but since this was reported earlier, the other should probable be marked as the duplicate.

Same thing going on between both.

The User says his system is using the 'r8169' module. One of the default in the 6.2 kernel Change Log for that module dealt directly with changing the default from highest speed to something "conservative" to avoid some problems some people were having with ASPM:

RE: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2

Quote:
"commit 32163491c0c205ffb1596baf9c308dee5338ae94
Merge: 65e6af6cebefb 42f66a44d8371
Author: David S. Miller <email address hidden>
Date: Sat Dec 3 21:49:23 2022 +0000

Merge branch 'r8169-irq-coalesce'

Heiner Kallweit says:

====================
net: add and use netdev_sw_irq_coalesce_default_on()

    There are reports about r8169 not reaching full line speed on certain
    systems (e.g. SBC's) with a 2.5Gbps link.
    There was a time when hardware interrupt coalescing was enabled per
    default, but this was changed due to ASPM-related issues on few systems.

    Meanwhile we have sysfs attributes for controlling kind of
    "software interrupt coalescing" on the GRO level. However most distros
    and users don't know about it. So lets set a conservative default for
    both involved parameters. Users can still override the defaults via
    sysfs. Don't enable these settings on the fast ethernet chip versions,
    they are slow enough.

Even with these conservative setting interrupt load on my 1Gbps test
system reduced significantly.

    Follow Jakub's suggestion and put this functionality into net core
    so that other MAC drivers can reuse it.
    ====================

Signed-off-by: David S. Miller <email address hidden>"

I'm thinking that this change may have happened and may occur because of that default change.

Same thing going on between both.

The User says his system is using the 'r8169' module. One of the default in the 6.2 kernel Change Log for that module  dealt directly with changing the default from highest speed to something "conservative" to avoid some problems some people were having with ASPM:

RE: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2

Quote:
"commit 32163491c0c205ffb1596baf9c308dee5338ae94
Merge: 65e6af6cebefb 42f66a44d8371
Author: David S. Miller <davem@davemloft.net>
Date:   Sat Dec 3 21:49:23 2022 +0000

Merge branch 'r8169-irq-coalesce'
    
    Heiner Kallweit says:
    
    ====================
    net: add and use netdev_sw_irq_coalesce_default_on()
    
    There are reports about r8169 not reaching full line speed on certain
    systems (e.g. SBC's) with a 2.5Gbps link.
    There was a time when hardware interrupt coalescing was enabled per
    default, but this was changed due to ASPM-related issues on few systems.
    
    Meanwhile we have sysfs attributes for controlling kind of
    "software interrupt coalescing" on the GRO level. However most distros
    and users don't know about it. So lets set a conservative default for
    both involved parameters. Users can still override the defaults via
    sysfs. Don't enable these settings on the fast ethernet chip versions,
    they are slow enough.
    
    Even with these conservative setting interrupt load on my 1Gbps test
    system reduced significantly.
    
    Follow Jakub's suggestion and put this functionality into net core
    so that other MAC drivers can reuse it.
    ====================
    
    Signed-off-by: David S. Miller <davem@davemloft.net>"

I'm thinking that this change may have happened and may occur because of that default change.