Hi David, On 14.02.2019 03:45, David Chang wrote: > Hi Heiner, > > On Feb 05, 2019 at 19:50:30 +0100, Heiner Kallweit wrote: >> Hi David, >> >> meanwhile there's the following bug report matching what reported. >> It's even the same chip version (RTL8168h). >> https://bugzilla.redhat.com/show_bug.cgi?id=1671958 >> >> Symptom there is also a significant number of rx_missed packets. >> Could you try what I mentioned there last: >> Try building a kernel with the call to rtl_hw_aspm_clkreq_enable(tp, true) >> at the >> end of rtl_hw_start_8168h_1() being disabled. > > After disabled the aspm function that you mentioned, we finally got the > positive testing result. And the rx_missed error was gone. If without > the patch, the receive side get back to bad performance. > Good to know, thanks. I also checked with Realtek, they confirmed that their Windows driver uses some heuristics to disable ASPM under high load. So it seems like there is some hw issue. Open so far is whether this affects certain chip versions only. Let's see whether they can provide more information. Disabling ASPM in general would hurt notebook users because based on some past measurements we know ASPM can significantly save energy.
> kernel: r8169: loading out-of-tree module taints kernel. > kernel: r8169: module verification failed: signature and/or required key > missing - tainting kernel > kernel: libphy: r8169: probed > kernel: r8169 0000:01:00.0 eth0: RTL8168h/8111h, ec:8e:b5:5a:2c:f5, XID > 54100880, IRQ 128 > kernel: r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx > checksumming: ko] > kernel: r8169 0000:01:00.0 enp1s0: renamed from eth0 > kernel: Generic PHY r8169-100:00: attached PHY driver [Generic PHY] > (mii_bus:phy_addr=r8169-100:00, irq=IGNORE) > kernel: r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control off > > NIC statistics: > tx_packets: 1653804 > rx_packets: 1555966 > tx_errors: 0 > rx_errors: 0 > rx_missed: 0 > align_errors: 0 > tx_single_collisions: 0 > tx_multi_collisions: 0 > unicast: 1555884 > broadcast: 78 > multicast: 4 > tx_aborted: 0 > tx_underrun: 0 > > iperf receive: > ----------------------------------------------------------- > Server listening on 5201 > ----------------------------------------------------------- > Accepted connection from 10.x.x.x, port 55516 > [ 5] local 10.x.x.x port 5201 connected to 10.x.x.x port 58172 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 108 MBytes 906 Mbits/sec > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec > [ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec > [ 5] 5.00-6.00 sec 112 MBytes 942 Mbits/sec > [ 5] 6.00-7.00 sec 112 MBytes 939 Mbits/sec > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec > [ 5] 8.00-9.00 sec 112 MBytes 938 Mbits/sec > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec > [ 5] 10.00-11.00 sec 112 MBytes 941 Mbits/sec > [...] > [ 5] 50.00-51.00 sec 112 MBytes 941 Mbits/sec > [ 5] 51.00-52.00 sec 112 MBytes 941 Mbits/sec > [ 5] 52.00-53.00 sec 112 MBytes 942 Mbits/sec > [ 5] 53.00-54.00 sec 112 MBytes 941 Mbits/sec > [ 5] 54.00-55.00 sec 111 MBytes 934 Mbits/sec > [ 5] 55.00-56.00 sec 112 MBytes 942 Mbits/sec > [ 5] 56.00-57.00 sec 112 MBytes 937 Mbits/sec > [ 5] 57.00-58.00 sec 112 MBytes 941 Mbits/sec > [ 5] 58.00-59.00 sec 111 MBytes 932 Mbits/sec > [ 5] 59.00-60.00 sec 112 MBytes 942 Mbits/sec > [ 5] 60.00-60.04 sec 4.06 MBytes 939 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate > [ 5] 0.00-60.04 sec 6.57 GBytes 940 Mbits/sec receiver > > regards, > David > Heiner
