La connexion Internet filaire est très lente sous Ubuntu 16.04.03 LTS
J'ai un serveur HP Proliant exécutant Ubuntu 16.04.03 LTS et lorsque j'effectue un test de vitesse, je n'obtiens que des vitesses de téléchargement de 3,5 Mbps. Sur un ordinateur portable Windows sur le même réseau, je reçois des vitesses de téléchargement de 29 Mbps.
Ils utilisent tous les deux une connexion filaire avec une carte réseau gigabit sur un réseau gigabit, et le serveur est directement connecté au routeur ADSL. Le serveur NIC est:
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
J'ai essayé de désactiver ipv6, mais cela ne faisait aucune différence. Quelqu'un at-il des suggestions quant à ce que je devrais essayer? Merci d'avance.
MISE À JOUR 12 janvier 2018
Je pense maintenant que ce n'est pas un problème avec la carte réseau. J'ai testé la copie de fichiers de 100 à 500 Mo sur mon réseau local et je peux facilement obtenir des taux de transfert de 300 Mbps ou plus. Donc, clairement, il n'y a pas de gros problème avec la carte réseau.
Le problème semble se poser car j'utilise speedtest-cli, qui est une implémentation python permettant d’utiliser le réseau de serveurs speedtest.net. Lorsque je lance speedtest-cli, il signale une vitesse de ~ 3,5 Mbps, lorsque je teste le téléchargement d'un fichier volumineux sur Internet, j'obtiens ~ 3,5 Mbps (octets, bits non plus).
$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
Je me demandais si speedtest-cli était mal calibré, en rapportant des bits au lieu d'octets, mais je ne le pense pas. Dans ce cas, il semble y avoir un bug dans le logiciel.
Je me demande si quelqu'un d'autre a vu ce comportement?
Exécutez dans votre terminal avec le numéro de port Ethernet que vous utilisez. Ici, j'ai supposé qu'il s'agissait de 'eth0':
Sudo /sbin/ethtool eth0
et voyez si le mode duplex est Half ou Full. S'il s'agit d'un semi-duplex, modifiez-le en duplex intégral à l'aide de cette commande:
Sudo /sbin/ethtool -s eth0 full
Vous pouvez également modifier le port Ethernet en semi-duplex avec cette commande:
Sudo /sbin/ethtool -s eth0 half
Cependant, vous devez d'abord installer ethtool si vous n'en avez pas.
J'ai trouvé la réponse à ma question ...
Il semble que les mauvais serveurs de noms DNS aient été configurés. Mon serveur a pour serveur de noms l'ancienne adresse IP du routeur et l'adresse IP actuelle du routeur. Bien que cela ait parfaitement fonctionné à la fin, il semble que le ralentissement de la recherche du site a ralenti, ce qui a rendu le temps imparti à speedtest-cli plus rapide au cours de ses 40 téléchargements de test, produisant une vitesse de téléchargement lente.
Le correctif consistait à mettre à jour le serveur de noms dans */etc/network/interfaces * vers 8.8.8.8 et à renvoyer la carte réseau. À présent, la vitesse est supérieure à 29 Mbits/s.