Wired internet connection is very slow on Ubuntu 16.04.03 LTS

Question

I have an HP Proliant Server running Ubuntu 16.04.03 LTS and when I run a speed test, I am only getting download speeds of 3.5Mbps. On a windows laptop on the same network I get download speeds of 29Mbps.

They are both using wired connection with a gigabit NICs on a gigabit network, and the server is connected directly to the ADSL router. The server's NIC is:

lspci -ks 02:00.0
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe (rev 10) 
Subsystem: Hewlett-Packard Company NC107i Integrated PCI Express Gigabit Server Adapter 
Kernel driver in use: tg3 
Kernel modules: tg3

I have tried disabling ipv6, but that made no difference. Does anyone have any suggestions as to what I should try? Thanks in advance.

UPDATE 12 Jan 2018

I now think that it is not a problem with the NIC. I tested copying 100-500MB files on my LAN and I can easily get 300+Mbps transfer rates. So clearly there is no great problem with the NIC.

The problem seems to arise because I am using speedtest-cli, which is a python implementation for using the speedtest.net network of servers. When I run speedtest-cli, it reports a speed of ~3.5Mbps, when I test the download of a large file over the internet I get ~3.5MBps (bytes not bits).

$wget --output-document=/dev/null http://ipv4.download.thinkbroadband.com/100MB.zip
--2018-01-12 15:39:24-- http://ipv4.download.thinkbroadband.com/100MB.zip 
Resolving ipv4.download.thinkbroadband.com 
(ipv4.download.thinkbroadband.com)... 80.249.99.148 
Connecting to ipv4.download.thinkbroadband.com 
(ipv4.download.thinkbroadband.com)|80.249.99.148|:80... connected. 
HTTP request sent, awaiting response... 200 OK 
Length: 104857600 (100M) [application/zip] 
Saving to: ‘/dev/null’ 

/dev/null 100%[===================>] 100.00M 3.60MB/s in 28s 

2018-01-12 15:39:57 (3.60 MB/s) - ‘/dev/null’ saved [104857600/104857600] 

$ speedtest-cli 
Retrieving speedtest.net configuration... 
Testing from TalkTalk (<redacted>)... 
Retrieving speedtest.net server list... 
Selecting best server based on ping... 
Hosted by CloudConnX (Eastbourne) [3.95 km]: 2525.195 ms 
Testing download speed................................................................................ 
Download: 3.63 Mbit/s 
Testing upload speed................................................................................................ 
Upload: 2.85 Mbit/s 

I wondered if speedtest-cli is calibrated wrongly, reporting bits instead of bytes, but I don't think so. In which case it seems to be a bug in the software.

I wonder if anyone else has seen this behaviour?

Solution 1

Run in your terminal with correct ethernet port number you are using. Here I assumed it is 'eth0':

sudo /sbin/ethtool eth0

and see if the duplex mode is Half or Full. If it is Half duplex change it to full duplex with this command:

sudo /sbin/ethtool -s eth0 duplex full

You can also change the ethernet port to Half duplex with this command:

sudo /sbin/ethtool -s eth0 duplex half

However you need to install the ethtool first if it is not yet installed.

Solution 2

I have found the answer to my question...

It seems that I had the wrong DNS nameservers set up. My server has as nameservers the former IP address of the router and the current IP address of the router. While this worked perfectly well in the end, it seems it was slowing down finding the site, which made speedtest-cli time out during its 40 test downloads, producing a slow download speed.

The fix was to update the name server in */etc/network/interfaces* to 8.8.8.8 and bounce the network adapter and now the speed is the more normal 29Mbps.

Solution 3

Running ubuntu 16.04.7 LTS using a bootable SSD, I found internet connectivity was very slow at one location but fine at another. Off a second 16.04 bootable SSD, internet connectivity was fine at both locations.

I noticed that extensive use of docker had created a lot of docker networks (15), which were visible as Active Network Connections from the standard network manager gui.

docker network prune

reduced these to only three and the problem went away. I think one of these networks had been holding up internet requests.

Comments

[Terrance]

Try a power reset of the host. Power it off, unplug all the power from the unit. Press the power button a few times without any power. Plug the power back in and power the system back up. I have had this help with many issues.

[Shaka Zulu]

Thanks for the suggestion, Nazmul. I have tried that, but it is already in full duplex mode.

[user962247]

actually, syntax is different (duplex full instead of just full)