Transferts réseau extrêmement lents dans un sens
Les transferts de fichiers de mon serveur domestique (sous Ubuntu 12.04 Server) vers un autre ordinateur de mon réseau local (tous sous Windows 7) sont extrêmement lents, mais les transferts de fichiers dans l'autre sens (téléchargement sur le serveur) sont rapides.
J'ai observé cela avec les transferts Samba et SFTP. J'ai donc décidé de le vérifier avec iperf et obtenu les mêmes résultats. La sortie sur le serveur ressemblait à ceci:
iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 5001 connected with 192.168.1.82 port 1309
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 416 MBytes 349 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.82, TCP port 5001
TCP window size: 46.1 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 59704 connected with 192.168.1.82 port 5001
[ 4] 0.0-12.2 sec 1.50 MBytes 1.03 Mbits/sec
Le client (My Win 7 PC) a généré cette sortie pour la même exécution:
iperf.exe -c 192.168.1.95 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.1.95, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.82 port 1309 connected with 192.168.1.95 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 416 MBytes 349 Mbits/sec
[ 4] local 192.168.1.82 port 5001 connected with 192.168.1.95 port 59704
[ 4] 0.0-12.2 sec 1.50 MBytes 1.03 Mbits/sec
Des résultats similaires sont observés chez d'autres clients. Les ordinateurs sont tous connectés au même commutateur câblé Gigabit. L'échange des ports et des câbles entre eux donne le même résultat.
L'exécution des transferts depuis et vers un disque virtuel configuré sur le serveur ne modifie pas non plus les vitesses de transfert; Je ne crois pas que le disque dur pose le problème.
J'ai fait de mon mieux pour rechercher des problèmes similaires sur Google, mais je n'ai pas encore trouvé de solutions pertinentes. Quelqu'un a-t-il une idée?
Vous trouverez ci-dessous quelques copies de commandes de débogage pertinentes, au cas où elles seraient utiles à des personnes plus informées que moi.
sortie ethtool pour la carte Ethernet sur le serveur:
ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
Mii-outil de sortie:
Sudo mii-tool
eth0: negotiated 1000baseT-HD flow-control, link ok
Liste du matériel retourné par lspci:
Sudo lspci
00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
00:08.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 Graphics [S3 UniChrome Pro] (rev 01)
Liste des pilotes chargés retournés par lsmod:
Sudo lsmod
Module Size Used by
usb_storage 39646 0
vesafb 13516 1
ppdev 12849 0
arc4 12473 2
snd_via82xx 24718 0
gameport 15060 1 snd_via82xx
snd_ac97_codec 110213 1 snd_via82xx
b43 342801 0
ac97_bus 12642 1 snd_ac97_codec
snd_pcm 80916 2 snd_via82xx,snd_ac97_codec
snd_timer 28931 1 snd_pcm
snd_page_alloc 14108 2 snd_via82xx,snd_pcm
snd_mpu401_uart 13865 1 snd_via82xx
snd_rawmidi 25424 1 snd_mpu401_uart
snd_seq_device 14172 1 snd_rawmidi
snd 62218 7 snd_via82xx,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
mac80211 436493 1 b43
soundcore 14635 1 snd
serio_raw 13027 0
i2c_viapro 12969 0
cfg80211 178877 2 b43,mac80211
bcma 25651 1 b43
parport_pc 32114 1
shpchp 32265 0
mac_hid 13077 0
via_cputemp 13031 0
hwmon_vid 12723 1 via_cputemp
lp 17455 0
parport 40930 3 ppdev,parport_pc,lp
pata_via 13428 0
ssb 50691 1 b43
r8169 56396 0
sata_via 13495 2
Informations sur le pilote pour la carte Gigabit:
Sudo modinfo r8169
filename: /lib/modules/3.2.0-51-generic-pae/kernel/drivers/net/ethernet/realtek/r8169.ko
version: 6.017.00-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew <[email protected]>
srcversion: 231149B837AF2B63F7C0271
alias: pci:v00001186d00004300sv00001186sd00004C00bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
depends:
vermagic: 3.2.0-51-generic-pae SMP mod_unload modversions 686
parm: speed:force phy operation. Deprecated by ethtool (8). (array of int)
parm: duplex:force phy operation. Deprecated by ethtool (8). (array of int)
parm: autoneg:force phy operation. Deprecated by ethtool (8). (array of int)
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
... et uname -a pour faire bonne mesure:
uname -a
Linux hotblack 3.2.0-51-generic-pae #77-Ubuntu SMP Wed Jul 24 20:40:32 UTC 2013 i686 i686 i386 GNU/Linux
Si quelqu'un pense qu'une autre sortie de débogage serait utile, n'hésitez pas à demander.
Mettre à jour
A défaut d'un meilleur moyen de tester un pilote différent, j'ai également essayé de revenir à un noyau plus ancien au démarrage, qui renvoyait r8169 vers v2.3LK-NAPI, mais le problème demeurait identique.
J'ai cependant fait une découverte intéressante. Si j'utilise ethtool pour forcer la carte à revenir à 100 Mo ...
Sudo ethtool -s eth0 speed 100 autoneg on duplex full
Sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
... puis iperf montre que la connexion fonctionne correctement dans les deux sens:
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 5001 connected with 192.168.1.82 port 2437
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 105 MBytes 87.7 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.82, TCP port 5001
TCP window size: 83.9 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 40844 connected with 192.168.1.82 port 5001
[ 4] 0.0-10.0 sec 113 MBytes 94.4 Mbits/sec
Je ne sais pas exactement quoi en conclure, mais c'est au moins une autre preuve que la vitesse de téléchargement n'est pas limitée par le matériel ...
J'ai déjà vu cela auparavant, causé par une non-concordance de duplex. La spécification pour Ethernet Gigabit requiert que les deux côtés utilisent la négociation automatique. Assurez-vous donc que la carte réseau du serveur et les clients sont configurés pour la négociation automatique, et qu'il en est de même pour vos ports de commutateur. La définition explicite de 1000/Full ne le fera pas explicitement.
Je vois dans l'une de vos sorties:
contrôle de flux négocié 1000baseT-HD, lien ok
Cela ressemble à du semi-duplex. Ce qui se produit lorsque les deux côtés ne sont pas réglés sur auto, c’est que la phase de négociation automatique détecte correctement la vitesse de transmission à 1 000 Mbits/s, mais ne peut pas détecter le mode duplex et utilise par défaut le mode semi-duplex. Vous avez donc 2 appareils qui tentent de communiquer, l’un en duplex intégral et l’autre en semi-duplex. Le résultat net est que le trafic d'un côté provoque beaucoup d'erreurs de paquets, ce qui oblige les paquets à être renvoyés et tue le taux de transfert dans cette direction.
J'ai corrigé un problème entre un serveur et une boîte NAS de cette façon, une carte a été définie sur auto et l'autre explicitement sur 1000/Full.
J'ai eu un problème similaire sur ma machine. Le téléchargement sur la machine était de 2 Mo/s alors que le téléchargement depuis la machine ne coûtait que 55 ko/s. J'ai essayé tous les trucs ci-dessus, des interrupteurs vérifiés, des câbles, etc., mais rien n'a fonctionné. Finalement, mon problème a été résolu: retirer la carte Ethernet du gestionnaire de réseau (set managed = false dans /etc/NetworkManager/NetworkManager.conf) et configurer le périphérique manuellement dans/etc/network/interfaces.
auto eth0
iface eth0 inet dhcp
Maintenant, je reçois 1Mo/s dans les deux sens.