[SOLVED] Ethernet throughput issues on Intel I225-V (igc)

vany64 · 2025-11-22 12:24:47

Hello,

I am experiencing very inconsistent and extremely low Ethernet performance on Arch Linux with an Intel I225-V controller. In a dual-boot setup with Windows 10, the exact same hardware, cable, and router deliver a stable 900 Mbit/s on Windows. On Arch Linux, the throughput fluctuates between 4 and 300 Mbit/s depending on the tool, and Firefox sometimes drops to 4–12 Mbit/s.

My network controller is an Intel I225-V (rev 03). ethtool -i eth0 reports the igc driver version 6.17.8-arch1-1 with firmware 1073:8754 (PCI ID 8086:15f3).

On Linux, WAN ping tests start losing packets above ~1360 bytes, with the router responding “Frag needed (mtu = ~1360)”, even though the router MTU is set to 1500. Windows sees the same path MTU constraint but maintains full performance, while Linux becomes extremely slow. Local pings to 192.168.1.1 show no packet loss.

In Wireshark on Linux, I see many TCP retransmissions, duplicate ACKs, fast retransmissions, and “previous segment not captured”. None of this appears when testing the same network flow on Windows.

Here is what I have already tried, with no improvement:
– disabling all offloading features via ethtool (tso, gso, gro, lro, sg, rx, tx)
– enabling net.ipv4.tcp_mtu_probing=1
– manually lowering the MTU (tested values between 1300 and 1400)
– Firefox safe mode and a fresh Firefox profile

At this point I am trying to understand whether this could be a regression in the igc driver, an MSS/TSO issue, or something else specific to this controller under Linux. I am looking for advice on further debugging steps or known fixes/workarounds for the I225-V on recent kernels.

I can provide any additional logs or captures (dmesg, ip link, PCAP excerpts, router details, etc.) if needed.

Thanks in advance for any help.

Last edited by vany64 (2025-11-23 17:43:58)

Lone_Wolf · 2025-11-22 12:49:06

You may be new to archlinux , but are definitely not new to networking.
Welcome to the forums.

Moderator Note
Moving to Networking, Server, and Protection subboard

vany64 · 2025-11-22 13:05:04

Thanks for the warm welcome, and thanks for moving the thread.
I’ll make sure to choose the correct subboard next time.

I also tried booting the LTS kernel to check whether the issue was kernel-related, and the problem persists there as well.

I removed all unused network managers and now rely only on NetworkManager, to avoid any possible conflicts.
Given the tests I’ve done so far (MTU behaviour, packet loss only above ~1360 bytes, large amounts of TCP retransmissions captured in Wireshark, normal performance under Windows, same symptoms on both the latest and LTS kernels), it increasingly looks like the issue may be related either to the igc driver for the Intel I225-V (rev 03) or to some low-level NIC configuration on Linux.

If there is any specific information or logs that would help with troubleshooting (dmesg, full ethtool -k, ip a, PCAP traces, router configuration, etc.), I can provide them.

Thanks again for your time.

tekstryder · 2025-11-22 13:36:02

I have nothing useful to add other than I have the same device and zero issues ever since building this system 2021.

03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)

Are you certain you've not conflicting network services?

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

-thc · 2025-11-22 14:08:17

I have this exact adapter with the same kernel/driver but

driver: igc
version: 6.17.8-arch1-1
firmware-version: 1085:8770

your firmware is too old. Did you probably miss the manual intervention back in June? If so, try the two pacman commands.

tekstryder · 2025-11-22 14:15:16

-thc wrote:

your firmware is too old.

Possible, but

firmware-version: 1073:8754

is just fine using no firmware packages whatsoever.

-thc · 2025-11-22 14:22:59

@vany64: Just to make sure - you have to disable hybrid standby in Windoze.

seth · 2025-11-22 14:52:05

Next to tekstryder's question:

In a dual-boot setup with Windows 10

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

wrt the MTU: do you use a VPN of sorts and do you get a better throughput w/ an MTU of 1240?

vany64 · 2025-11-22 17:21:47

Thanks for the replies.

I’ve applied everything that was suggested so far: systemd-resolved is now fully disabled/masked, NetworkManager is using only static DNS (1.1.1.1 / 8.8.8.8), resolv.conf is no longer being overwritten, and Windows Fast Boot is disabled both in the OS and in the BIOS/UEFI. So nothing “external” should be interfering with the network stack anymore.

Unfortunately the issue remains exactly the same: Windows gives me ~900 Mbit/s, while Arch is stuck at 1–5 Mbit/s in browsers and around 30–40 Mbit/s with speedtest-cli.

Everything on the Arch side *looks* correct: the igc driver loads normally, the link negotiates 1 Gbit, no drops or errors in `ethtool -S`, offloading features are enabled, and the kernel logs show nothing unusual (no PMTU/fragmentation/ICMP messages).
The only odd thing I can see is that my router consistently reports an MTU of 1460 when testing with `ping -M do`.

Here’s some info that might come in handy :

sudo modinfo igc 
filename:       /lib/modules/6.17.8-arch1-1/kernel/drivers/net/ethernet/intel/igc/igc.ko.zst
license:        GPL v2
description:    Intel(R) 2.5G Ethernet Linux Driver
srcversion:     483FBCE5B27CAF5EB5F4897
alias:          pci:v00008086d000015FDsv*sd*bc*sc*i*
alias:          pci:v00008086d0000125Fsv*sd*bc*sc*i*
alias:          pci:v00008086d0000125Esv*sd*bc*sc*i*
alias:          pci:v00008086d0000125Dsv*sd*bc*sc*i*
alias:          pci:v00008086d0000125Csv*sd*bc*sc*i*
alias:          pci:v00008086d0000125Bsv*sd*bc*sc*i*
alias:          pci:v00008086d00000D9Fsv*sd*bc*sc*i*
alias:          pci:v00008086d00005503sv*sd*bc*sc*i*
alias:          pci:v00008086d00005502sv*sd*bc*sc*i*
alias:          pci:v00008086d00003102sv*sd*bc*sc*i*
alias:          pci:v00008086d00003101sv*sd*bc*sc*i*
alias:          pci:v00008086d00003100sv*sd*bc*sc*i*
alias:          pci:v00008086d000015F7sv*sd*bc*sc*i*
alias:          pci:v00008086d000015F8sv*sd*bc*sc*i*
alias:          pci:v00008086d000015F3sv*sd*bc*sc*i*
alias:          pci:v00008086d000015F2sv*sd*bc*sc*i*
depends:        ptp
intree:         Y
name:           igc
retpoline:      Y
vermagic:       6.17.8-arch1-1 SMP preempt mod_unload 
sig_id:         PKCS#7
signer:         Build time autogenerated kernel key
sig_key:        62:71:9D:1A:80:81:07:4B:DA:3C:80:96:13:B8:D6:28:BC:A2:FE:B8
sig_hashalgo:   sha512
signature:      30:65:02:30:70:7C:59:43:74:4F:81:B4:07:BD:72:E8:D9:15:0B:A4:
                DA:19:91:FF:FD:54:D9:46:AE:04:BE:FF:A8:F1:E8:82:E7:90:3C:41:
                63:2C:E9:AF:0C:6F:5E:3E:A6:08:12:B2:02:31:00:88:5C:3F:09:28:
                92:BE:37:07:97:2B:38:D7:2A:D9:44:EE:15:FB:1D:00:91:C7:85:13:
                D3:C5:51:E8:CB:C0:61:88:1A:8A:7D:50:73:FF:10:BF:82:61:AE:31:
                F2:D1:6C
parm:           debug:Debug level (0=none,...,16=all) (int)

❯ sudo ethtool eth0                                                                                            ─╯
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

ethtool -k eth0                                                                                              ─╯
Features for eth0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: on
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: on
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: on
        tx-tcp-accecn-segmentation: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: on
tx-gre-csum-segmentation: on
tx-ipxip4-segmentation: on
tx-ipxip6-segmentation: on
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-gso-partial: on
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: on
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]

ethtool -S eth0                                                                                              
NIC statistics:
     rx_packets: 146392
     tx_packets: 88780
     rx_bytes: 187694209
     tx_bytes: 30685206
     rx_broadcast: 0
     tx_broadcast: 10
     rx_multicast: 476
     tx_multicast: 15
     multicast: 476
     collisions: 0
     rx_crc_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 3139
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 187694209
     tx_dma_out_of_sync: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     os2bmc_rx_by_bmc: 0
     os2bmc_tx_by_bmc: 0
     os2bmc_tx_by_host: 0
     os2bmc_rx_by_host: 0
     tx_hwtstamp_timeouts: 0
     tx_hwtstamp_skipped: 0
     rx_hwtstamp_cleared: 0
     tx_lpi_counter: 0
     rx_lpi_counter: 0
     qbv_config_change_errors: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_queue_0_packets: 9576
     tx_queue_0_bytes: 5475735
     tx_queue_0_restart: 0
     tx_queue_1_packets: 17369
     tx_queue_1_bytes: 8288223
     tx_queue_1_restart: 0
     tx_queue_2_packets: 45688
     tx_queue_2_bytes: 8982840
     tx_queue_2_restart: 0
     tx_queue_3_packets: 16147
     tx_queue_3_bytes: 7581710
     tx_queue_3_restart: 0
     rx_queue_0_packets: 27520
     rx_queue_0_bytes: 35579162
     rx_queue_0_drops: 0
     rx_queue_0_csum_err: 0
     rx_queue_0_alloc_failed: 0
     rx_queue_1_packets: 82775
     rx_queue_1_bytes: 109912272
     rx_queue_1_drops: 0
     rx_queue_1_csum_err: 0
     rx_queue_1_alloc_failed: 0
     rx_queue_2_packets: 18694
     rx_queue_2_bytes: 19691669
     rx_queue_2_drops: 0
     rx_queue_2_csum_err: 0
     rx_queue_2_alloc_failed: 0
     rx_queue_3_packets: 17403
     rx_queue_3_bytes: 21925538
     rx_queue_3_drops: 0
     rx_queue_3_csum_err: 0
     rx_queue_3_alloc_failed: 0

ip link show eth0                                                                                            
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

ping -M do -s 1472 8.8.8.8                                                                                  
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1460)
ping: sendmsg: Message too long

Additional local network test

To rule out any physical or LAN–related issue, I also ran an iperf3 test between my laptop (Wi-Fi) and my desktop (Ethernet).
The results are normal (around ~400–550 Mbit/s), so the LAN path and cabling are working correctly:

sudo iperf3 -s                                                                                               

-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.23, port 42450
[  5] local 192.168.1.81 port 5201 connected to 192.168.1.23 port 42452
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  59.4 MBytes   498 Mbits/sec                  
[  5]   1.00-2.00   sec  60.4 MBytes   506 Mbits/sec                  
[  5]   2.00-3.00   sec  65.9 MBytes   552 Mbits/sec                  
[  5]   3.00-4.00   sec  59.5 MBytes   499 Mbits/sec                  
[  5]   4.00-5.00   sec  48.6 MBytes   408 Mbits/sec                  
[  5]   5.00-6.00   sec  40.4 MBytes   339 Mbits/sec                  
[  5]   6.00-7.00   sec  49.5 MBytes   415 Mbits/sec                  
[  5]   7.00-8.00   sec  56.4 MBytes   472 Mbits/sec                  
[  5]   8.00-9.00   sec  61.2 MBytes   514 Mbits/sec                  
[  5]   9.00-10.00  sec  43.6 MBytes   366 Mbits/sec                  
[  5]  10.00-10.01  sec  1.00 MBytes   618 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec   546 MBytes   457 Mbits/sec                  receiver
-----------------------------------------------------------

Everything looks consistent on the Arch side, yet the download speed is still extremely low only on Linux.
If anyone has an additional idea to test, or any experience with a similar Connect Box setup, I’d appreciate it.

Last edited by vany64 (2025-11-22 18:54:06)

-thc · 2025-11-22 20:10:11

This feels like a path MTU issue. So changing the MTU via

nmcli c modify --temporary 'EthernetConnectionID' 802-3-ethernet.mtu 1460

doesn't change anything?

seth · 2025-11-22 20:15:31

both in the OS and in the BIOS/UEFI

Fast-boot in the BIOS isn't relevant, only windows fast-start (because that secretly hibernates the system resulting in the same HW being controlled by two OS at the same time)

iperf3 test between my laptop (Wi-Fi) and my desktop (Ethernet). The results are normal

From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1460)

So, yeah - what if you substantially lower the MTU?
The fragmentation likely happens WAN side ie. your ISP will add some overhead.

Edit: F5ck

Last edited by seth (2025-11-22 20:15:52)

vany64 · 2025-11-23 17:01:57

Hello Everybody,

Just a quick update to let you know that the issue is now fully resolved.
Thanks again for the suggestions and the time you took to help.

Your replies encouraged me to thoroughly review and clean up my setup. In the process I found several leftover configurations and a few inconsistencies, and running a full fsck was also required. I also disabled Windows Fast Boot to rule out any hardware state persistence between reboots. After cleaning up the system and removing old configuration fragments, I ended up with a much more consistent baseline.

Once everything was updated and cleaned, I decided to switch fully back to systemd-networkd and systemd-resolved, not because NetworkManager caused any conflicts, but simply because I prefer this setup for its simplicity and clarity. After that change, the Intel I225-V has been performing normally again.

For completeness: instead of lowering the MTU directly on the interface, I restored the interface MTU to 1500 and added a clean nftables rule to clamp TCP MSS according to the effective WAN path MTU. This prevents fragmentation and keeps the network stack behaving predictably. Since then, the connection has been perfectly stable, with 800–900 Mbit/s and no retransmissions or PMTU issues.

I still can’t attribute the fix to a single change, but the system is now clean and working exactly as expected.

Thanks again. Your input definitely pointed me in the right direction.

See you around the forums!
Vany64

Last edited by vany64 (2025-11-23 17:02:34)

Arch Linux

#1 2025-11-22 12:24:47

[SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#2 2025-11-22 12:49:06

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#3 2025-11-22 13:05:04

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#4 2025-11-22 13:36:02

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#5 2025-11-22 14:08:17

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#6 2025-11-22 14:15:16

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#7 2025-11-22 14:22:59

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#8 2025-11-22 14:52:05

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#9 2025-11-22 17:21:47

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#10 2025-11-22 20:10:11

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#11 2025-11-22 20:15:31

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

#12 2025-11-23 17:01:57

Re: [SOLVED] Ethernet throughput issues on Intel I225-V (igc)

Board footer