Pourquoi ai-je 950 Mbps, mais seulement 360 Mbps sur Gigabit Ethernet?
J'ai deux ordinateurs de bureau qui se parlent directement. Ils ont tous les deux des adaptateurs réseau compatibles Gigabit Ethernet. C'est 1 Gbps ou 1000 Mbps. Je les ai connectés à un tout nouveau câble Cat6 UTP droit de 10 mètres de longet je me rapproche de ce maximum théorique. Le Gestionnaire de tâches Windows (onglet Réseau) affiche 844 à 946 Mbps dans un sens. Mais dans l’autre sens, il n’indique qu’environ 326 - 365 Mbps.
Local: 192.168.100.152
Remote: 192.168.100.151
L'ordinateur local exécute Windows 8.1 Pro et je l'ai connecté à distance à l'autre ordinateur qui exécute Windows Vista Ultimate.
résultats Iperf
J'ai utilisé Iperf pour faire des tests. J'ai exécuté le test pendant 60 secondes à chaque fois. J'ai fait le test 10 fois pour chaque sens de la communication. J'ai ensuite mis en place ce tableau avec les résultats des tests pour obtenir une moyenne.
192.168.100.152 -> 192.168.100.151 106 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 104 MB/s
192.168.100.152 -> 192.168.100.151 101 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
----------------------------------------------------
Min: 101 MB/s Max: 108 MB/s Avg: 106.4 MB/s (851.2 Mbps)
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
-----------------------------------------------------
Min: 41.0 MB/s Max: 41.1 MB/s Avg: 41.07 MB/s (328.56 Mbps)
Ma question est la suivante: pourquoi est-ce tellement plus lent dans l'autre sens?
Gestionnaire de tâches Windows
Ceci est le diagramme de réseau tel que vu lors de l'exécution des tests dans Iperf.
Faites attention au diagramme dans les deux captures d'écran suivantes!
Avez-vous remarqué comment il est passé de "1 Gbps" à "500 Mbps" dans le coin supérieur droit lorsque je suis passé de l'envoi de données à la réception de données. Pourquoi a-t-il fait cela? Est-il en quelque sorte en train de détecter sur l'autre port du réseau la valeur de moitiéde 1 Gbps en allant dans un sens, mais pourtant pleinen faisant l'inverse?
Test de transfert de fichier
J'ai fait d'autres tests avec un fichier de données pour obtenir des lectures plus réalistes d'un disque à l'autre. J'ai créé un fichier de 1 Go à cet effet. J'ai utilisé uniquement les installations de partage de fichiers Windows par défaut. À partir de l'ordinateur local, je me suis connecté au partage C $ sur l'ordinateur distant, puis j'ai glissé et déplacé le fichier (saut à la corde) entre eux, en changeant le nom du fichier à chaque fois. J'ai tout chronométré au mieux de mes capacités et c'est ce que j'ai obtenu.
192.168.100.152 -> 192.168.0.151 1073741824 Byte 25 s 40,96 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 20 s 51.2 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 16 s 64 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 16 s 64 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 34 s 30.118 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
Le débit indiqué par le diagramme de copie de fichier Windows raconte une histoire différente. Ici, je télécharge deux fichiers, l'un après l'autre, vers deux emplacements différents sur le même disque. La première copie indiquait 107 Mo/s maintenus jusqu'à 41%, et la seconde 98,9 Mo/s maintenus jusqu'à 87%.
Cela correspond donc aux résultats obtenus avec l'outil Iperf. Voici à quoi cela ressemble quand je télécharge sur l’ordinateur distant.
Il maintient 103 Mo/s jusqu'à 73%, puis cède à 27,3 Mo/s à 82%, puis monte d'un cran pour atteindre 49,1 Mo/s à 93%.
Voici deux autres diagrammes de "montagnes russes" plus drôles.
Mise à jour 1 - Vitesse de la liaison
J'ai essayé de désactiver l'adaptateur Wifi sur l'ordinateur distant. (L'adaptateur Wifi était déjà désactivé sur l'ordinateur local.) Je pense que c'est ce que Timtech entendait par ce commentaire. J'avais la même idée: avoir activé simultanément les adaptateurs filaires et sans fil limitait le débit de l'adaptateur filaire au niveau de l'adaptateur Wifi (adaptation à l'adaptateur le plus lent pour la compatibilité). Parce que l’adaptateur Wifi (le DWA-160 Wireless N dans ce cas) est généralement détecté par l’ordinateur Vista comme liaison "52 Mbps" - "104 Mbps".
Dans la capture d'écran suivante, l'ordinateur distant est configuré en tant que serveur et l'ordinateur local en tant que client (192.168.100.152 <- 192.168.100.151).
Toutefois, la déconnexion de l'adaptateur Wifi sur l'ordinateur distant n'a pas aidé mon faible débit sur ma connexion filaire.
Non seulement que! Dans le Gestionnaire des tâches Windows de l'ordinateur distant, la vitesse de liaison de l'adaptateur câblé (LAN 1) est définie sur "1 Gbps". Si vous vous référez aux captures d'écran ci-dessus, vous constaterez qu'il est détecté comme un lien "500 Gbps" sur l'ordinateur local. Donc, pour la même connexion filaire, Windows Vista dit que c'est un lien de 1 Gbps, alors que dans le même temps, Windows 8.1 Pro dit que c'est un lien de 500 Gbps ... lequel est-ce exact?
Voici à quoi cela ressemble sur l'ordinateur distant lorsque je le configure en tant que client et que l'ordinateur local en tant que serveur (192.168.100.152 -> 192.168.100.151).
Comme vous pouvez le voir ici, environ 95% de la liaison 1 Gbps est utilisée. Cela se traduit par 950 Mbps. C'est exactement ce que j'ai dans le test ci-dessus. Mais l'inverse est une toute autre histoire.
Mise à jour 2 - Duplexage et MDI-X
Comme suggéré par certains d’entre vous, j’ai jeté un œil aux paramètres de duplex. Les ordinateurs locaux et distants étaient tous deux configurés en mode de négociation automatique, comme le montrent les captures d'écran ci-dessous.
J'ai essayé de passer à "1.0 Gbps Full Duplex" sur les deux ordinateurs. J'ai ensuite fait le même type de tests que précédemment, en utilisant Iperf. Avec un ordinateur local en tant que serveur et un ordinateur distant en tant que client, je reçois environ 950 Mbps maximum. Avec un ordinateur local en tant que client et un ordinateur distant en tant que serveur, je reçois environ 360 Mbps.
Ici, regardez ces captures d'écran.
Ce que vous voyez ici est le diagramme pour quand je télécharge et télécharge entre les deux ordinateurs. Le graphique le plus élevé (utilisation de 95 à 98%) est local à distant (192.168.100.152 en amont -> 192.168.100.151 en amont). Le graphique inférieur (utilisation ~ 33%) est distant au local (aval 192.168.100.152 <- 192.168.100.151).
Pour tenter d'éliminer tout problème lié à Auto MDI-X, l'un de ces adaptateurs croisés était connecté à une extrémité du câble (l'ordinateur local).
Cela ferait certainement du câble un câble croisé. Bon sang, je l'ai même fait tester avec un testeur de réseau! Il est en effet croisé maintenant (pins 1/3, 2/6)!
Alors maintenant, j’ai une véritable connexion par câble croisé entre les deux ordinateurs, et j’ai défini manuellement "1.0 Gbps Full Duplex". Pourtant, j'ai toujours le même problème. Plus d'idées? Outre la mise à niveau de l'ordinateur Vista (ou la réinstallation de l'ordinateur 8.1)?
Mise à jour 3 - Limitations logicielles ou matérielles?
Ma meilleure hypothèse est que j'ai deux systèmes d'exploitation incompatibles. Ce sont deux systèmes Windows, mais tous les systèmes Windows ne sont pas égaux. Je vais devoir utiliser Vista sur les deux ou 8.1 Pro sur les deux et voir quel type de débit je reçois. Cela signifie acheter une mise à niveau. Bon sang Microsoft.
Les deux ordinateurs sont construits sur mesure. Voici quelques spécifications.
Local
-----
Gigabyte GA-EP45-UD3R
Intel Core 2 Quad Q9650
Intel P45
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Realtek 8111C chips (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows 8.1 Pro 64-bit
Remote
------
Gigabyte GA-X38-DQ6
Intel Core 2 Duo E4500
Intel X38
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Dual Realtek 8111B chip (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows Vista Ultimate 64-bit
Tonny a suggéré que la machine Vista utilise peut-être une mauvaise puce Realtek. J'ai donc déterré ces spécifications. Je vois maintenant que la machine Vista utilise une révision B de 8111 alors que la machine locale utilise une révision C de la même puce. Est-ce que ça veut dire quelque chose? Ils sont tous deux clairement spécifiés pour 1000 Mbit (voir ci-dessus) par le fabricant. Se pourrait-il que 8111B sous-performe autant (360 Mbps)?
Ces lecteurs particuliers atteignent un taux de rafales de 107 Mo/s. C'est exactement le nombre que j'ai vu lors du test sur l'ordinateur local. Mais même la lecture/écriture séquentielle ou aléatoire soutenue de peut-être 55 Mo/s ne se traduit pas par 360 Mbps. Cela devrait me donner quelque part autour de 440 Mbps, et non les 360 Mbps que je reçois. Donc, je ne pense pas que cela soit le goulot d'étranglement, d'autant plus qu'ils utilisent tous les deux le même modèle de disque. De plus, la copie de fichier est une chose, mais Iperf n’utilise pas du tout de disques, il utilise uniquement la mémoire RAM pour les tests.
Mise à jour 4 - TCP Déchargement de la somme de contrôle
Comme suggéré par Tonny, j'ai essayé de désactiver TCP déchargement de la somme de contrôle (pour IPv4 et IPv6).
J'ai également commuté "Speed & Duplex" sur Auto pour les deux ordinateurs. Mais cela n'a pas aidé. J'ai toujours le faible débit dans une direction et élevé dans l'autre direction.
Update 5 - Nouvelle version du pilote
J'ai essayé de mettre à jour la version du pilote à la fois locale et distante vers la dernière version téléchargée depuis les sites Web Gigabyte et Realtek.
Update path...
On local (RTL8111C):
8.1.510.2013 (2013-05-10, Microsoft)
8.20.815.2013 (2013-08-15, Realtek)
On remote (RTL8111B):
6.241.623.2010 (2010-06-23, Realtek)
6.250.908.2011 (2011-09-08, Realtek)
6.252.1109.2012 (2012-11-09, Realtek)
J'ai toujours le même débit moche dans une direction.
Mise à jour 6 - Utilisation de la CPU
J'ai vérifié l'utilisation du processeur. Cela ne devrait pas être un problème. Voici mes conclusions.
On local...
Download: 4 - 10 %
Upload: 4 - 10 %
Idle: 0 - 4 %
On remote...
Download: 24 - 38 %
Upload: 10 - 25 %
Idle: 1 - 6 %
Local (téléchargement, téléchargement, inactif) ...
À distance (télécharger, télécharger, inactif) ...
La télécommande utilise beaucoup plus de puissance de calcul, mais c'est également celle avec le Core 2 Duo plus lent. Mais il n’a jamais dépassé les 38% lors de mes tests. Ce qui est particulièrement intéressant ici, c’est qu’il utilise beaucoup plus de puissance de calcul lors du téléchargement (local -> distant) que lors du téléchargement (local <- distant).
Donc, avec un débit de 950 Mbps, il utilise 38% et à 360 Mbps, il utilise 25%. De plus, l'utilisation principale n'est pas équilibrée, elle utilise un cœur plus que l'autre. Je ne suis pas sûr de la conclusion à tirer de cela. L'ordinateur local n'affiche pas l'utilisation principale, donc je ne peux pas le comparer. Mais l'utilisation du processeur se fait même sur l'ordinateur local (10% sur le téléchargement).
Mise à jour 7 - Nouvelle carte réseau Intel Gigabit
J'ai maintenant installé une toute nouvelle carte réseau PCI-Express Gigabit d'Intel en remplacement du Realtek RTL8111B intégré sur l'ordinateur distant, ce qui est censé être trop lent pour le téléchargement. Le numéro de produit de l'adaptateur Intel est EXPI9301CT. Cet adaptateur est censé être très bon d'après les critiques que j'ai lues. Je veux juste exclure cela comme un goulot d'étranglement possible.
J'ai déjà testé Iperf pour Windows et voici les résultats.
Local (télécharger, télécharger) ...
À distance (télécharger, télécharger) ...
En moyenne, cet adaptateur est en réalité un peu plus lent que l'adaptateur Realtek. Je pense que les frais généraux sont moins importants que ceux de Realtek et que, par conséquent, le débit en continu est plus stable. Mais je n’ai toujours que 360 Mbps dans un sens et 950 Mbps dans l’autre, même avec cet adaptateur Intel.
local: 192.168.100.152 (win 8, realtek 8111c)
remote: 192.168.100.154 (Vista, intel desktop ct)
192.168.100.152 -> 192.168.100.154 113 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 103 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 102 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 101 MB/s
192.168.100.152 -> 192.168.100.154 102 MB/s
192.168.100.152 -> 192.168.100.154 101 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
----------------------------------------------
Max: 113 MB/s Min: 101 MB/s Avg: 103.8 MB/s
192.168.100.152 <- 192.168.100.154 42.2 MB/s
192.168.100.152 <- 192.168.100.154 41.2 MB/s
192.168.100.152 <- 192.168.100.154 41.1 MB/s
192.168.100.152 <- 192.168.100.154 43.0 MB/s
192.168.100.152 <- 192.168.100.154 42.3 MB/s
192.168.100.152 <- 192.168.100.154 42.3 MB/s
192.168.100.152 <- 192.168.100.154 40.2 MB/s
192.168.100.152 <- 192.168.100.154 40.9 MB/s
192.168.100.152 <- 192.168.100.154 41.3 MB/s
192.168.100.152 <- 192.168.100.154 42.0 MB/s
-----------------------------------------------
Max: 43.0 MB/s Min: 40.2 MB/s Avg: 41.65 MB/s
Je ne sais pas pourquoi il a culminé à 113 Mo/s lors du premier test, de local à distant. Il a gardé cette vitesse tout au long du test, le graphique était presque plat à 113 Mo/s. Comme auparavant, j'ai utilisé un intervalle de 60 secondes pour chaque exécution. Lors de la prochaine exécution, il est tombé à 104 Mo/s.
Comme vous pouvez le constater à l'aide de ces valeurs, j'ai toujours le même débit avec cet adaptateur Intel qu'avec l'adaptateur Realtek intégré. Je pense donc qu'il est prudent de dire que cela n'a rien à voir avec l'adaptateur lui-même. Donc, nous pouvons cesser de blâmer RTL8111B comme étant une puce inférieure/inférieure à la RTL8111C trouvée sur l’autre carte mère. Cela ressemble de plus en plus à un problème logiciel/système d'exploitation/configuration, ou aux trois choses à la fois.
Mise à jour 8 - Excellents résultats avec Ubuntu LINUX
Après avoir épuisé toutes les autres options, j'ai finalement décidé de faire quelques tests avec Linux et j'ai obtenu d'excellents résultats. J'ai utilisé un système Ubuntu Linux 13.10 Live et Iperf pour Linux (version 2.0.5-3) sur les ordinateurs local et distant. Voici les résultats.
=======================================================
REALTEK 8111C <-> REALTEK 8111B | IPERF ON UBUNTU LINUX
=======================================================
local: 192.168.100.152
remote: 192.168.100.151
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
----------------------------------------------
Max: 112 MB/s Min: 112 MB/s Avg: 112 MB/s
192.168.100.152 <- 192.168.100.151 110 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 110 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
----------------------------------------------
Max: 111 MB/s Min: 110 MB/s Avg: 110.8 MB/s
Local (téléchargement, téléchargement, inactif) ...
Comme vous pouvez le constater, j'obtiens le même débit dans les deux sens avec Ubuntu. Est-ce parce que j'utilise le même système d'exploitation sur les deux machines ou est-ce autre chose? Aurais-je le même débit si j'avais les mêmes versions de Windows configurées sur les deux machines? Je ne comprends pas pourquoi il importerait que j'utilise une version de Windows légèrement obsolète, à savoir Vista, sur une machine et la dernière version sur l'autre? ... Je veux dire que Vista est toujours un système d'exploitation actuel, pris en charge et sauvegardé par Microsoft. . Windows XP est une autre histoire.
Mais je sais qu'ils font tout ce qu'ils peuvent pour tuer Vista. Par exemple, le dernier Office 2013 n'est intentionnellement pas pris en charge sur Windows Vista. Je suis sûr que Microsoft souhaite que Vista ne se soit jamais produit. Tout comme ils souhaiteraient que Windows 8.0 ne soit jamais arrivé. Mais en général, je suis tout aussi persistant et je ne mets pas à niveau mes installations Windows tant que je ne le dois pas.
La question est donc de savoir comment obtenir le même débit dans les deux sens avec deux versions différentes de Windows. Windows Vista devrait pouvoir prendre en charge la vitesse Gigabit - ce n'est pas un système d'exploitation vieux de 20 ans ou quelque chose du genre, ce n'est pas Windows 95 dont nous parlons. Vista est un système d'exploitation moderne. Je n'ai pas encore testé la même version de Windows sur les deux machines. Il peut y avoir une différence dans la mise en œuvre TCP ou quelque chose entre les deux versions du système d'exploitation. Si tel est le cas, je serai probablement obligé de mettre à niveau la machine Vista. Soit ça ou basculer vers Linux. Je ne suis pas prêt à payer plus pour moins. Pourquoi devrais-je mettre à niveau Windows uniquement pour obtenir un débit Gigabit dans les deux sens? ...
Mise à jour 9 ...
Câble
J'ai essayé d'inverser le câble. J'ai eu les mêmes résultats qu'avant. J'ai également eu un nouveau câble de raccordement de cat. 6 et essayé celui-là. Les résultats des tests de débit étaient les mêmes. Donc, le câble n'est pas la question ici. Je n'ai utilisé que des câbles de raccordement pré-terminés/moulés. Donc, le câblage devrait être correct. Mais je prévois de terminer mes propres câbles d'installation plus tard.
FW et AV
En ce qui concerne les pare-feu (FW) et les anti-virus (AV), je n’utilise aucun logiciel FW ou AV tiers. Je n'ai que le pare-feu Windows et Security Essentials. Je les ai désactivés tous les deux sur les deux machines. Les résultats des tests de débit étaient les mêmes que précédemment.
Test de vitesse LAN
J'ai installé LAN Speed Test Lite 1.3 sur la machine locale. Je crois que le test est effectué entre la mémoire sur le disque local et le lecteur de disque sur la machine distante. Je ne suis pas sûr. Mais il demande un chemin de partage sur la machine distante. J'ai utilisé o $ share sur la télécommande.
Upload: 427 Mbps
Download: 420 Mbps
Je ne fais pas trop confiance à ces résultats. Si vous regardez le graphique, vous constaterez qu'il varie beaucoup tout au long du test. Le test était un test "successif", c'est-à-dire: test d'écriture (téléchargement) en premier, puis test de lecture (téléchargement). Évidemment, si vous effectuez un test de téléchargement/téléchargement simultané, le débit global sera plus faible. Mais je ne suis pas intéressé par de tels tests. Jusqu'ici, je n'ai fait que des tests "successifs" avec les tests de transfert de fichiers sous Windows (partage de fichiers/smb) et sous Iperf.
Je n'ai effectué aucun test de mémoire à mémoire avec LAN Speed Test car il nécessite l'utilisation d'un programme appelé LST Server sur la télécommande et ce programme nécessite un enregistrement pour pouvoir être utilisé.
Mise à jour 10 ...
Tests du lecteur de disque
J'ai utilisé Crystal Disk Mark 3.0.3 pour tester les lecteurs de disque. Voici les résultats.
Local disk: 118 MB/s read, 113 MB/s write
Remote disk: 70 MB/s read, 69 MB/s write
Il s’agit de vitesses de lecture et d’écriture séquentielles basées sur 5 cycles et une charge de 1000 Mo.
C'est le disque local (marque, lecture, écriture) ...
Et c'est le disque distant ...
Mais je ne comprends pas cela ... ces résultats semblent contradictoires.
Cependant, le disque local peut lire à 118 Mo/s, ce qui permettrait un téléchargement d'environ 100 Mo/s. Mais le disque distant ne pourra pas le recevoir s'il est seulement capable d'écrire à 69 Mo/s. Mais par magie, je reçois toujours un peu plus de 100 Mo/s en moyenne.
Faire l'inverse a plus de sens. Si le disque distant peut lire à 70 Mo/s et si le disque local peut écrire à 113 Mo/s, le téléchargement ne devrait pas dépasser 70 Mo/s. Je reçois environ 40 Mo/s de téléchargement en moyenne. Cela semblerait raisonnable.
Donc, je ne peux rien conclure de ces résultats. Je veux dire que le lecteur de disque sur l'ordinateur local est à peine utilisé. C'est également le disque qui contient le système d'exploitation, et c'est la seule partition de ce système. Alors que le disque distant est presque plein, il est également partitionné en plusieurs partitions. Cependant, il n'est pas utilisé pour le système d'exploitation. J'ai choisi la lettre de lecteur O: pour le test ici, car c'est la partition avec le plus d'espace libre.
(Notez que j'ai utilisé la lettre de lecteur C: lors des tests précédents, qui se trouve sur un lecteur de disque Seagate complètement distinct contenant le système d'exploitation sur l'ordinateur distant. Ces lectures ne sont donc pas comparables.)
écrire en cache
Avec la mise en cache d'écriture sur disque activée, j'ai obtenu ces résultats.
Local to remote: 106 MB/s
Remote to local: 42.2 MB/s
J'ai ensuite désactivé la mise en cache en écriture sur tous les lecteurs de la télécommande et du lecteur local.
Je n'ai pas redémarré car aucun redémarrage n'a été demandé pour que les modifications prennent effet. J'ai ensuite eu les résultats suivants.
Local to remote: 106 MB/s
Remote to local: 42.1 MB/s
Il n'y avait pratiquement pas de changement du tout. Pas de redémarrage, et aucun redémarrage n'a été demandé.
paquet QOS
J'ai ensuite désactivé le planificateur de paquets QOS pour l'adaptateur approprié sur la machine distante, puis sur la machine locale.
Local to remote: 107 MB/s
Remote to local: 41.9 MB/s
Pas de changement significatif ici. Encore une fois, aucun redémarrage et aucun redémarrage n'a été demandé.
paquets Jumbo
J'ai ensuite activé les paquets jumbo. J'ai utilisé le paramètre 4 Go car 4 Ko correspond à la taille de MTU la plus grande prise en charge sur les deux machines.
Local to remote: 105 MB/s
Remote to local: 33.3 MB/s
Maintenant, ici, le téléchargement (local à distant) n’a pas été affecté, mais le débit de téléchargement a été réduit de manière significative. Aucun redémarrage n'a été demandé, mais j'ai quand même décidé de redémarrer les deux machines, juste pour faire bonne mesure. J'ai ensuite refait les mêmes tests et obtenu ces résultats.
Local to remote: 117 MB/s
Remote to local: 33.2 MB/s
Ainsi, le téléchargement est maintenant encore plus rapide, mais le téléchargement est toujours plus lent qu'avant les modifications, même après le redémarrage. Je me serais attendu à ce que les deux montent un peu. Qu'est-ce que ça veut dire?
Basé sur votre réponse:
@ewhac La taille de la fenêtre TCP sur l'ordinateur local est généralement différente de celle de l'ordinateur distant. La valeur par défaut est 0,06 Mo sur local (victoire 8) et 0,01 Mo sur à distance (Vista). Doivent-ils avoir la même valeur? Comment lui demander de deviner le MSS? Serait-ce le commutateur -m ("print maximum segment size")? Je ne règle généralement rien de tout cela. Pourquoi devrais-je? - Sammy 30 novembre à 21h39
La taille de la fenêtre TCP représente la quantité maximale de données que la pile TCP jettera à l'aveugle avant de s'arrêter et d'attendre la réception des accusés de réception de la machine distante - autrement dit, le maximum quantité de trafic non acquitté sur le réseau. Le fait que la fenêtre TCP de la machine Vista soit beaucoup plus petite que celle de la machine Windows Se7en confirme la théorie selon laquelle vous ne remplissez pas suffisamment le tuyau avant de vous caler et d'attendre les ACK.
Par conséquent, la première chose que je voudrais essayer est d’augmenter la taille de la fenêtre TCP sur la machine Vista à l’aide de l’argument -w. 0,01Mo est une unité peu utile; Je suppose que c'est 16 Ko. Commencez avec 16 Ko et effectuez un test:
iperf -c -w 16K ...
Doublez la taille de la fenêtre et répétez le test:
iperf -c -w 32K ...
J'espère que vous devriez observer une augmentation de la vitesse. Continuez à doubler la taille de la fenêtre jusqu'à ce que vous ne constatiez plus d'augmentation de vitesse significative.
Comme indiqué précédemment, vous devrez modifier la taille de la fenêtre TCP dans iperf pour obtenir un débit supérieur sur les liaisons haut débit à faible temps de latence. Différentes versions de Windows (ou iPerf) peuvent avoir des tailles de fenêtre par défaut différentes. Essayez "-w 256k" pour commencer avec à la fois le client et le serveur.
Pouvez-vous confirmer la direction de la flèche de vos cartes? Dans iPerf, les données sont poussées de du client vers le serveur (contrairement à ce que je pense habituellement).
Vous pouvez exclure les disques durs comme cause, car iPerf ne touche pas les disques durs.
Je pense que vous avez déjà vérifié que vous utilisez les derniers pilotes NIC. Il ne devrait pas être nécessaire de perdre du temps avec le réglage manuel de la vitesse/du duplex. Même chose avec les trames géantes - elles ne valent pas la peine avec du matériel moderne.
Vérifiez que les déchargements importants (LSO) et les déchargements importants de réception (LRO) sont activés sur les deux cartes réseau. Certains pilotes NIC utilisent des noms différents (ou plusieurs options contrôlant ce comportement). Vous devrez donc peut-être vous débrouiller. Le plus souvent, par défaut, ils sont tous activés.
Je pense que vous devez lire un peu plus sur le fonctionnement de iperf. Si vous ne définissez pas la taille correcte de la fenêtre TCP, vos résultats varieront beaucoup. Je crois que c'est le commutateur -w. Ce site Web vous aidera à calculer la taille optimale de la fenêtre TCP. Vous devez connaître le RTT et la bande passante pour le calculer. http://www.kehlet.cx/docs/tcpwin.php
Essayez également d’autres outils tels que "LAN Speed Test" lite, qui effectuent uniquement des transferts ascendants et descendants entre les actions, à chaque extrémité. Ses résultats sont assez proches dans les essais réalisés avec elle. Assurez-vous également de vérifier les vitesses maximales de votre disque dur.
Quelques points qui pourraient vous aider. TCP La pile IP est maintenant implémentée différemment dans les versions postérieures à Windows 7. J'examinerais de près mes optimisations TCP: il n'y aurait peut-être pas grand chose entre vos deux boîtes, mais vous auriez peut-être intérêt à modifier certains paramètres de votre Vista Box.
L'utilisation de netsh int tcp set fournisseur global de congestion = ctcp a été dépréciée. Afin de définir ou de modifier le fournisseur d'encombrement, la commande suivante doit être utilisée:
lisez l'article ici: http://forums.speedguide.net/showthread.php?280646-When-will-TCP-Optimizer-support-Windows-8-amp-Windows-Server- 2012
netsh int tcp défini personnalisé supplémentaire 300 10 ctcp désactivé 50 Tapez ensuite: netsh int tcp défini personnalisé supplémentaire
Pour plus de détails sur la commande ci-dessus, tapez simplement: netsh int set supplemental
Pour vérifier quel fournisseur de congestion vous utilisez actuellement, utilisez ce qui suit: netsh int tcp show supplemental
Mais seul Win Server 2012 peut créer des modèles personnalisés CTCP peut-être un problème.
La mise à l'échelle automatique pourrait également être un facteur.
Cela vaut peut-être la peine de jeter un coup d'œil sur vos pilotes qui ont peut-être besoin d'une mise à niveau/dégradation. voir ceux qui fonctionnent le mieux.
Une autre idée concerne les tailles de paquet écrites sur le disque dur. De quelle taille vos secteurs de disque dur sont-ils formatés de 512b à 64 Ko? Cela pourrait être un goulot d'étranglement en cache. Cela vaut la peine d'être pris en compte lors de l'utilisation de vitesses GBit ou de tester avec un disque SSD!
Avez-vous envisagé d'activer les paquets géants (si cela s'applique à votre carte réseau)?
Essayez d’arrêter le service MMCSS. Oui, vous perdrez temporairement votre fichier audio, mais il est possible que quelque chose l'active, ce qui provoque une limitation de l'activité du réseau, de sorte que l'activité du réseau n'englobe pas d'autres activités.
Voir ici quelques informations sur MMCSS et la régulation du réseau: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
Il peut être modifié selon les instructions suivantes: http://support.Microsoft.com/kb/948066
Je doute que ce soit la cause dans ce cas, car le débit serait probablement plus faible, mais après avoir heurté ma tête contre le mur pendant longtemps avec mes propres problèmes de débit sous Vista, j'ai découvert que c'était la cause. J'ai fixé NetworkThrottlingIndex à 70 et j'ai finalement obtenu le débit auquel je m'attendais.
Excellents résultats avec Ubuntu LINUX
Cela semble assez familier ... vous obtenez inexplicablement de mauvaises performances iperf dans Windows, mais le même matériel fonctionne bien avec Linux.
Après avoir combattu cette bataille encore et encore, je suis parvenu à la conclusion que iperf dans Windows est floconneux . Je ne sais pas pourquoi ... honnêtement, j'ai arrêté de m'inquiéter parce que je sais que je peux toujours obtenir des résultats sains de Linux.
Donc, si vous voulez savoir pourquoi vous obtenez une si mauvaise performance, ne cherchez pas plus loin que l'application.
Une chose que vous n'avez pas essayée est de supprimer la compression différentielle à distance sous Vista.
Ma réflexion est motivée par l'utilisation intensive du processeur sur Vista. Il se peut que le pilote de réseau Vista ne sache pas comment le décharger sur la carte réseau, alors que Windows 8 le fait beaucoup plus efficacement.
Pour plus de détails, voir l'article:
Empêchez la copie de fichier lente sur le réseau dans Vista en désactivant la compression différentielle à distance .
En un mot, décochez simplement Remote Differential Compression dans Panneau de configuration -> Programmes et fonctionnalités -> Activer et désactiver les fonctionnalités de Windows, puis redémarrez.
Auparavant, je poursuis ma queue avec exactement le même problème pendant un moment! Des vitesses de transfert lentes dans un sens, dans mon cas sortant (liaison montante).
Windows 7 Pro, Celeron J1800 avec carte réseau intégrée Realtek Gigabit 8111C. QNAP 453a et MacBook Pro à l’autre bout.
Mesuré via Iperf3, j’obtenais 112 Mbps avec Windows 7 comme client (utilisation du processeur entre 25 et 30%). Et seulement 39-41 Mbps en tant que serveur, avec une utilisation intensive du processeur entre 50 et 100%. Si mal que le PC se fige lors des tests de bande passante.
Le transfert de fichiers normal est limité à 45 Mbps maximum, peu importe si je télécharge ou télécharge des fichiers sur mon NAS ou mon MAC.
Je n'obtenais rien de plus que 35 à 45 mégaoctets par seconde. Assez frustrant!
En fin de compte être un mauvais conducteur de carte LAN. J'étais obsédé par la mise à jour des pilotes et je mettais toujours mes pilotes à jour lorsque de nouveaux pilotes sont disponibles. Devinez quoi, après plusieurs mises à jour, ma carte LAN a ralenti.
Certains d'entre vous pourraient dire, il suffit de supprimer l'ancien pilote et d'installer le nouveau. Simple, ah? J'ai essayé et essayé, cela n'a pas fonctionné pour moi.
Voici ma solution:
Windows installé à partir de zéro avec les pilotes OEM du site Web du fabricant. De plus, j'ai fait ce qui suit:
Sous Gestionnaire de périphériques/Carte réseau/Paramètres avancés/Désactiver tout sauf FLOW CONTROL.
Sous Fonctionnalités Windows, désactivez la compression différentielle à distance.
Maintenant, la vitesse moyenne est comprise entre 80 et 100 Mbps.
Désolé pour les photos de mauvaise qualité.
