e1000e driver - uploading slowed to a crawl.

[DiagonalArg]

I have a Thinkpad T520 and a W520, both with the same ethernet device, Intel 82579LM.

When the T520 is running under Windows, speedtest reports ~0.93Gb down & ~1.05Gb up, so the hardware is good. Under Ubuntu 18.04, kernel 4.15.0-50, I get ~0.7Gb down but only a very reporoducible 4.15Mb (!) up. The W520 responds the same.

e1000e is version 3.2.6-K and e1000 is version 7.3.21-k8-NAPI.

Note that I also have a Thinkpad T530 which has the same Intel 82579LM and is running the same e1000 and e1000e driver versions, but under Ubuntu 16.04 (kernel 4.4.0-146). That is giving me ~.7Gb down and ~0.35Gb up. Better, but still definitely 1/3 of link capacity.

I have tried a number of attempted solutions which have had no effect:

ethtool -K eth0 gso off gro off tso off
ethtool -K eth0 tx off rx off
ethtool -G eth0 tx 256 rx 256
ethtool -G eth0 tx 8096 rx 8096
ethtool --set-eee eth0 eee off; ethtool --set-eee eth0 advertise 0
Turning off ASPM in BIOS and via the kernel parameter pcie_aspm=off

Note also that I also have a Dell Optiplex 980 with an 82578DM running CentOS which had a similar problem (4.8Mb up). Turning off ASPM in BIOS partially corrected the issue there. I now have speeds very similar to the Thinkpad T530 (~0.7Gb down, ~0.35Gb up)

I also note that there is another issue with this driver that was never resolved: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766377

Finally, I tried to install the most recent version of the e1000 and e1000e drivers, but they do not compile under Ubuntu 18.04 and I am now told this is no longer supported: https://sourceforge.net/p/e1000/bugs/643/

---

ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dev 2052 F.... pulseaudio
CurrentDesktop: MATE
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=7c310224-1fd2-472b-91a8-2d3f3001642c
InstallationDate: Installed on 2018-08-31 (264 days ago)
InstallationMedia: Ubuntu-MATE 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
MachineType: LENOVO 4284A94
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-50-generic root=UUID=36d8a469-5f40-46de-887d-90fbd0b4aa3b ro rootflags=subvol=@ quiet splash vt.handoff=1
ProcVersionSignature: hostname 4.15.0-50.54-generic 4.15.18
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-50-generic N/A
 linux-backports-modules-4.15.0-50-generic N/A
 linux-firmware 1.173.6
Tags: bionic
Uname: Linux 4.15.0-50-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom debian-tor dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 10/20/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: 8BET63WW (1.43 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4284A94
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8BET63WW(1.43):bd10/20/2016:svnLENOVO:pn4284A94:pvrThinkPadW520:rvnLENOVO:rn4284A94:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.family: ThinkPad W520
dmi.product.name: 4284A94
dmi.product.version: ThinkPad W520
dmi.sys.vendor: LENOVO

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1830197

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

apport information

[DiagonalArg (diagonalarg)]

I reported this error here, but received no response: https://sourceforge.net/p/e1000/bugs/643/

[Jan Vesely (jan.vesely)]

I've run into similar problem, and I don't think it's e1000e driver issue.

My device:
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)
 Subsystem: Dell 82579LM Gigabit Network Connection (Lewisville)
 Kernel driver in use: e1000e
 Kernel modules: e1000e

speedtest-cli gives:
Download: 93.51 Mbit/s
Testing upload Upload: 3.91 Mbit/s

However, if I run speedtest from fedora VM on the same machine it gives:
Download: 93.40 Mbit/s
Upload: 68.75 Mbit/s

it doesn't even have to be a VM. Running docker:
$ docker run --rm -it fedora:latest /bin/bash
[root@e4d188a07bff /]# dnf install -y speedtest-cli
...
[root@e4d188a07bff /]# speedtest-cli
...
Download: 81.67 Mbit/s
Upload: 39.02 Mbit/s

However:
$ docker run --rm fedora:latest dnf install -y speedtest-cli && speedtest-cli
...
...
...
Download: 93.48 Mbit/s
Upload: 3.86 Mbit/s

More experiemnts:
$ docker run --rm -it fedora:latest dnf install -y speedtest-cli && speedtest-cli
...
...
...
Download: 93.48 Mbit/s
Upload: 3.86 Mbit/s

finally, $ docker run --rm -it fedora:latest /bin/bash -c "dnf install -y speedtest-cli && speedtest-cli"
...
...
Download: 93.46 Mbit/s
Upload: 66.97 Mbit/s

so it looks like ubuntu is detecting interactive processes and deprioritizing everything else

[Jan Vesely (jan.vesely)]

Oh and it's also for certain hosts. Connecting to a host on the same network gives reliable 96Mbps.

[Jan Vesely (jan.vesely)]

some more testing:
latest == bionic:
docker run --rm -it ubuntu:latest /bin/bash -c "apt-get update && apt-get upgrade && apt-get install -y speedtest-cli ca-certificates && speedtest-cli"
Download: 93.44 Mbit/s
Upload: 3.95 Mbit/s

xenial:
docker run --rm -it ubuntu:xenial /bin/bash -c "apt-get update && apt-get install -y speedtest-cli ca-certificates && speedtest-cli"
Download: 88.55 Mbit/s
Upload: 37.09 Mbit/s

disco:
docker run --rm -it ubuntu:disco /bin/bash -c "apt-get update && apt-get install -y speedtest-cli ca-certificates && speedtest-cli"
Download: 93.52 Mbit/s
Upload: 36.26 Mbit/s

so the 4 Mbit/s upload limitation exists only on bionic

[DiagonalArg (diagonalarg)]

You know what, now that you've pointed to it, while speedtest-cli produces the 4Mb upload rate, if i go to https://www.speedtest.net/, I get 1Gb symmetric. I'm on 16.04. Could it be a problem with speedtest-cli itself?

[Jan Vesely (jan.vesely)]

I'm not sure if speedtest-cli directly or something in python or one of the involved libraries.
I was investigating it because appveyor CI images suffered extremely long upload speeds, but that got fixed between Dec 18th and 19th. I haven't investigated what the change was, but there was a point release of every python version around that time.