Oh!
OK...because I just tested a laptop too:
Its specs claim to be: Intel I2xx /825xx.
just to be sure. you have an X86 router, with openwrt, using an intel NIC : Intel I2xx /825xx, which use the driver e1000e
Then you made a nperf from your PC, and everything works fine, as i can see on your graph ?
- I have a X68_64 router with a dual port e1000e / PCI-E card / 82571GB.
- The laptop is e1000e/Intel I2xx /825xx
I ran SpeedTeset dot net (and other speed test sites), I will try nperf (as I noted - never tried).
I've done this just in testing both thru the router and with the laptop alone...that's why I was confused. I've never seen such a drop...and in fact until I read this thread, would have preferred Intel chips for network speed testing.
So it could be related to the software?
No drop Intel laptop thru Intel router NICs == 3 total.
well so looks like the e1000e driver works well with your 82571GB card.
if we campare it with the I217/219 Nics, we can see that the 82571GB is really older, and maybe that's why the e1000e driver works well with it ? i don't know
https://ark.intel.com/content/www/us/en/ark/compare.html?productIds=82185,20720,60019
1 Like
whoua !! and i was complaining... 
Don't you have some offloading settings disabled ? Tcp checksum ? i don't remember the ethool command to see this.
maybe ethtool -i eth0 (or what ever your wan interface is)
Laptop alone:
Whatever is default, I didn't install ethtool on this particular machine.
???
If you mean the variations and not hitting/sustaining, getting near 1 Gbps, I've only seen those results running nperf tests thus far.
root@OpenWrt:~# ethtool -i eth1
driver: e1000e
version: 3.2.6-k
firmware-version: 5.6-2
expansion-rom-version:
bus-info: 0000:01:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
2 Likes
yes it depends on many parameters, so we can't really compare your results with mine.
can you try
ethtool -K eth1
ethtool -k eth1
1 Like
lol, I just found the command myself...
Here goes:
root@OpenWrt:~# ethtool -k eth1
Features for eth1:
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: off [fixed]
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: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
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: off [fixed]
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]
1 Like
interesting, so you have RX/TX checksum set to ON, TSO/GSO set to ON
everything that could make the connection reset for I217/219 Nics is working fine with your card.
So in this case the e1000e driver works well.
The problem doesn't manifest on every card/ system but it is recurring in the sense that this is common among multiple generations of devices and rears its ugly head from time to time. I also have unaffected systems which just work - and others where I had to lobotomize the eeprom features (sadly serveral of the cards falling into either category are soldered onboard, so don't allow cross-checking).
1 Like
For wireless, yes. For wired, I'd skip them because they couldn't care less about FOSS. Vote with your wallet.
But yes, Broadcom NICs are pretty common in server stuff.
well, looks like this is how intel fixes the problem : disable TS0
https://sourceforge.net/p/e1000/bugs/614/
https://sourceforge.net/p/e1000/bugs/507/
here, someone say that there is no problem with kernet 4.19, the problem started for him since kernel 5.2/5.3 :
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1714048.html
Which openwrt X86_64 version is using a 4.x kernel that i can try ?
19.07 runs 4.14.
Thanks ! I was afraid I would have to use something much older
Out of curiosity, why not try one of the BSDs (or just pfsense/opnsense)? It would be interesting to know if you're running into the same issue there.
i tried already, but i was facing another problem, i was stuck at 40Mbps, probably because of my usb3/ethernet adapter ? as I don't know much about pfsense I didn't go further
i installed debian 11 on my HP 600G1, and i made a nperf.com several time without any problem at all, no curve crash, with default settings.
ethtool -i en01 gave me :
version : 5.10.0-14-amd
firmware version : 0.13-4
from openwrt 21.02.3, the version is 3.2.6-k, isn't it a bit outdated ??
You're looking at the kernel version... Not at the driver version. Check dmesg to find out about the driver version. Firmware version might be relevant too if it needs firmware.
modinfo should work for driver/module version, too.
1 Like
Ahh, you're mixing NICs with USB devices?
If you're stuck at 40Mbit it sounds like a USB2 vs USB3 issue? Can't say much about performance using USB NICs though as I've honestly never tried, if you have a box with PCIe NICs I can give you a hand if you want to give it a try using FreeBSD 13.1 just to see if it also craps out.
1 Like