Mise à jour
Ok, j'ai essayé les réponses ci-dessous et rien n'a changé. J'ai identifié le chipset dans l'ordinateur portable comme le NVIDIA nForce 520. J'ai téléchargé les derniers pilotes Vista x64 pour le nForce 520 (NVIDIA n'a pas encore de pilotes pour ce chipset pour Win 7). J'ai essayé d'installer le logiciel de pare-feu inclus (pensant peut-être que cela interfère - ce n'est pas le cas). J'ai complètement désinstallé mon logiciel anti-virus (j'utilise Avast!) Pensant que son pilote de filtre réseau peut causer un problème, cela n'a pas aidé non plus.
J'ai amené mon ordinateur portable chez mes frères et j'ai pu copier des fichiers à 10 - 12 Mo / s sur son réseau 100Mbit, donc je ne pense pas que ce soit le matériel.
J'ai exécuté iperf avec des résultats surprenants:
iperf de l'ordinateur portable envoyant au serveur (téléchargement)
> iperf -c naru
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[328] local 192.168.7.100 port 8549 connected with 192.168.7.6 port 5001
[ ID] Interval Transfer Bandwidth
[328] 0.0-10.0 sec 162 MBytes 136 Mbits/sec
> iperf -c naru -w 64k
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[328] local 192.168.7.100 port 8550 connected with 192.168.7.6 port 5001
[ ID] Interval Transfer Bandwidth
[328] 0.0-10.0 sec 1.06 GBytes 909 Mbits/sec
iperf du serveur envoyant à l'ordinateur portable (téléchargement)
> iperf -c miyuki
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[256] local 192.168.7.6 port 51871 connected with 192.168.7.100 port 5001
[ ID] Interval Transfer Bandwidth
[256] 0.0-10.1 sec 25.2 MBytes 20.8 Mbits/sec
> iperf -c miyuki -w 64k
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[256] local 192.168.7.6 port 51872 connected with 192.168.7.100 port 5001
[ ID] Interval Transfer Bandwidth
[256] 0.0-10.0 sec 21.1 MBytes 17.6 Mbits/sec
Pour comparaison, voici les numéros iperf entre le HTPC et le serveur
Server: Naru, Host: CC (CC sends to Naru)
iperf -c naru: 0.0-10.0 sec 363 MBytes 305 Mbits/sec
iperf -c naru -w 64k: 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec
Server: CC, Host: Naru (Naru sends to CC)
iperf -c cc: 0.0-10.0 sec 322 MBytes 270 Mbits/sec
iperf -c cc -w 64k: 0.0-10.0 sec 1020 MBytes 855 Mbits/sec
L'utilisation de Wireshark pour surveiller un transfert du serveur vers l'ordinateur portable permet de récupérer un grand nombre des entrées suivantes:
(:51aa is the server, :37a1 is the laptop)
No. Time Source Destination Proto Info
37785 27.286240 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#13] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40517974
37786 27.286258 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#14] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40519414
37787 27.286277 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#15] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40520854
37788 27.286295 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#16] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40522294
37789 27.286313 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#17] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40523734
37790 27.286332 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#18] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40525174
37791 27.286351 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#19] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40526614
37792 27.286370 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Previous segment lost] [TCP segment of a reassembled PDU]
37793 27.286372 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP segment of a reassembled PDU]
37794 27.286375 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Fast Retransmission] [TCP segment of a reassembled PDU]
37795 27.286377 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37796 27.286379 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37797 27.286382 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37798 27.286413 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#20] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40529494 SLE=40499254 SRE=40526614
37799 27.286432 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#21] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40530934 SLE=40499254 SRE=40526614
À ce stade, je ne sais plus quoi faire ensuite.
Question d'origine
Contexte
Je rencontre actuellement un problème sur mon ordinateur portable Windows 7 fraîchement installé. Le problème est survenu à l'origine après avoir installé Windows 7 RC. Lorsque Windows Vista et Windows 7 Bêta 1 ont été installés sur cet ordinateur portable, j'ai pu transférer à des vitesses gigabit avec des trames Jumbo activées sur la plage 9 Ko / 9014. Les deux commutateurs entre l'ordinateur portable prennent également en charge les trames Jumbo.
Lors de la copie de fichiers de mon serveur vers mon ordinateur portable, ils fonctionnent à un rythme d'escargot (généralement moins de 1 Mo / sec) tandis que d'autres appareils passant par les mêmes commutateurs peuvent transférer à des vitesses plus élevées (45-55 Mo / sec). Il semble que la copie de l'ordinateur portable vers le serveur soit plus rapide, mais rien de tel ne devrait l'être.
Machines impliquées
- Miyuki: Ordinateur portable avec le problème. Windows 7 x64 RTM. CTO HP Pavilion dv9700. Utilise un adaptateur Ethernet NVIDIA nForce 10/100/1000 Mbps. (La vidéo est GeForce 8400M GS)
- Naru: serveur avec fichiers. Windows Server 2008 R2 x64 SP2 personnalisé. Utilise un adaptateur Gigabit PCI Express D-Link DGE-560T.
- CC: HTPC sur le même commutateur sans problème. Windows Vista x86 SP2. Utilise un adaptateur GBE PCI-E Realtek RTL8168B / 8111B embarqué.
Lorsque ces images ont été prises, les images jumbo ont toutes été désactivées.
Les images
Copie initiée depuis l'ordinateur portable
Serveur -> Ordinateur portable (source: gibixonline.com )
Ordinateur portable -> Serveur
Copie initiée depuis le serveur
Serveur -> Ordinateur portable (source: gibixonline.com ) Le
fait que le serveur copie de façon inattendue un fichier de l'ordinateur portable sur lui-même entraîne des vitesses que j'attendrais. (Ordinateur portable -> Serveur) (source: gibixonline.com )
J'ai déclaré plus tôt que l'autre machine sur le même commutateur n'a pas ce problème. Le DPI élevé est activé car il est affiché sur un téléviseur HD.
Serveur -> HTPC (source: gibixonline.com )
Naturellement, comme test, j'ai décidé de voir quelles étaient les vitesses entre mon ordinateur portable et le HTPC. Malheureusement, ils étaient exactement ce à quoi je m'attendais.
HTPC -> Laptop (source: gibixonline.com )
Notes finales
J'ai essayé tout ce à quoi je peux penser. Même les trames jumbo sont désactivées à ce stade et rien ne semble l'affecter. J'ai essayé de désactiver ma protection antivirus pour changer les câbles que j'utilise. Actuellement, tous les câbles utilisés sont des CAT-5e que j'ai construits. J'ai essayé de prendre le câble du HTPC et de le brancher sur mon ordinateur portable pour voir si le câblage était un problème. Les deux commutateurs en question sont un D-Link DGS-1216T et un commutateur "muet" qui prend en charge les trames jumbo, le D-Link DGS-2208.
Réponses:
Essayez de désactiver la fonction de réglage automatique de Windows.
Dans une fenêtre CMD:
Relancez votre test et voyez si vous remarquez une amélioration des performances. J'ai dû le faire sur quelques ordinateurs portables exécutant Windows 7 chez moi, et cela m'a aidé.
Si les choses empirent ou si vous ne remarquez aucune amélioration, vous pouvez réactiver l'autoréglage en:
la source
Cela semble être un gros problème avec Windows 7. Plusieurs joueurs se sont plaints de ce problème.
Cela a réduit mon ping dans la plupart des jeux de 200 à 300 ms à 50 à 60 ms, ce qui correspond à la latence que je verrais via un tracert vers le serveur du jeu.
Tiré de la réduction de la latence du réseau de jeu dans Windows 7 ou Vista
la source
Pour vérifier si l'ordinateur portable n'est pas en cause, lancez un ubuntu live cd, installez iperf sur le ramdisk et lancez un test.
Cela devrait au moins tester le côté réseau de celui-ci.
la source
Vérifiez les paquets perdus. Je ne sais pas comment faire cela dans Windows, mais si vous avez une machine Linux, vous pouvez y vérifier.
J'ai eu une expérience similaire avec un commutateur gigabit où le mode gigabit était cassé et abandonnait des paquets. Je n'ai vu de problème que lorsque 2 machines étaient connectées dans ce mode. En mode 100K, tout allait bien. C'était un vilain problème qui m'a pris quelques jours pour le découvrir. J'étais peut-être un D-Link. Faites quelques recherches sur votre modèle de commutateur. Je l'ai fait et j'ai trouvé que d'autres avaient le même problème que moi.
la source
J'ai déjà rencontré cela avec d'autres produits AV. Mon problème était avec SMB et le produit AV interférait même lorsqu'il était "désactivé". Il a montré des résultats similaires dans wirehark que vous avez. Voici l'un des nombreux sites que j'ai vérifiés pour en arriver à la cause première: problème Symantec SMB et un autre: échec SMB2 avec NTP
En outre, vous pouvez essayer de désactiver / modifier tout ou partie des paramètres de SMB. J'envisagerais même de désactiver la v2 sur le système d'exploitation. Consultez cet article qui décrit un problème SMB dans Win Vista et ce lien vers Microsoft décrit certaines données techniques sur les paramètres d' enregistrement SMB .
Je sais que vous avez mentionné Avast, mais il est assez fortuit que j'ai vu des résultats de wirehark similaires. Notez que tout sauf le transfert de fichiers semble bien fonctionner dans mon cas.
la source
J'ai rencontré des problèmes avec les clients qui communiquent avec les serveurs Windows lors de l'utilisation de la signature de paquets. Je n'ai pas connu de lenteur, mais plutôt des abandons de connexion très courants.
Lisez ici pour la solution qui a résolu mon problème.
De plus, je ne vois aucune suggestion ici pour désactiver les fonctions TCP Chimney une par une pour voir si l'une d'entre elles a mal tourné.
la source
Il semble que le système d'exploitation vérifie les paquets avant d'écrire sur le disque. J'ai observé que tous les transferts lents sont ceux qui essaient d'écrire sur un ordinateur portable ... Je suggère
D'autres sont suggérées et ne semblent pas aider:
Une dernière suggestion est la suivante: pouvez-vous vérifier la détection des liens du mode batterie sur les propriétés avancées de nic? C'est un ordinateur portable et il pourrait y avoir des problèmes avec les propriétés d'économie d'énergie ... Essayez "Aucune économie d'énergie" sur la détection de liaison du mode batterie et "Complet" sur les paramètres de vitesse de la batterie.
J'utilise win7 sur un ordinateur de bureau et ces options ne sont pas incluses dans les propriétés avancées de mon nic. Tant que je n'avais jamais rencontré ce problème, vous pouvez également vérifier les valeurs de "Flow Control" à "TX and RX Enabled" comme options de mon nic. Jumbo est désactivé, la vitesse et le duplex sont également automatiques sur ma configuration ...
Je ne pense à aucune autre solution ... J'espère que cela aide ...
la source
Auparavant, je poursuis ma queue avec exactement le même problème pendant un certain temps! Vitesses de transfert lentes dans un sens, dans mon cas sortant (liaison montante).
Windows 7 Pro, Celeron J1800 avec carte LAN intégrée Realtek Gigabit 8111C. QNAP 453a et MacBook Pro à l'autre bout.
Lorsque mesuré via Iperf3, j'obtenais 112 Mbps avec mon Windows 7 défini comme client (utilisation du processeur à 25-30%). Et seulement 39-41 Mbps lorsqu'il est défini comme serveur, avec une utilisation intensive du processeur entre 50 et 100%. Tellement mauvais que le PC se fige lors des tests de bande passante.
Transfert de fichiers régulier limité à 45 Mbps maximum, que 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!
A fini par être un mauvais pilote de carte LAN. J'étais obsédé par la mise à jour des pilotes et j'ai toujours mis à jour mes pilotes lorsque de nouveaux pilotes étaient disponibles. Devinez quoi, après plusieurs mises à jour, ma carte LAN a ralenti.
Certains d'entre vous pourraient dire, supprimez simplement l'ancien pilote et installez le nouveau. C'est simple, ah? J'ai essayé et essayé, ça n'a pas marché pour moi.
Voici ma solution:
Windows installé à partir de zéro avec des pilotes OEM sur le site Web du fabricant. J'ai également fait ce qui suit:
Sous Gestionnaire de périphériques / Carte LAN / Paramètres avancés / Désactivez tout, sauf FLOW CONTROL.
Sous Fonctionnalités Windows, désactivez la compression différentielle à distance.
Désormais, la vitesse moyenne se situe entre 80 et 100 Mbps.
la source
Par tout, je suppose que vous avez défini les cartes réseau en duplex intégral, 100 Mo et non en mode automatique?
la source
Vous détesterez probablement cette réponse, mais je dois le dire!
Avez-vous essayé de mettre à jour les pilotes?
J'ai un problème similaire sur mon ordinateur portable (carte réseau basée sur Realtek), il transfère à environ 3 Mo / s, mais au moment où je mets à niveau les pilotes vers les derniers depuis leur site, il monte à environ 40 à 50 Mo / s.
Ce n'est pas parce que les pilotes avec Windows fonctionnent qu'ils sont les meilleurs.
la source
Je soupçonne que c'est quelque chose sur le chemin du serveur à l'ordinateur portable, par exemple:
Selon l'excellente suggestion de @ SaucemanSpiff, avez-vous essayé de câbler l'ordinateur portable directement au serveur à l'aide d'un bon câble CAT5E ou CAT6? Il n'y a pas besoin d'un câble croisé spécial tant qu'au moins une des interfaces impliquées prend en charge Gigabit Ethernet (ce qui implique Auto MDI-X).
la source
Vous avez battu le PC à mort avec des mises à jour et l'avez testé hors site sans échec. Avez-vous essayé de faire des mises à jour et autres sur le SERVEUR "naru"?
La plupart des solutions de ce fil suggérées par d'autres pourraient s'appliquer au serveur, les avez-vous essayées là-bas?
Que se passe-t-il lorsque vous testez avec Robocopy (avec et sans jumbo)? S'il est rapide dans les deux sens, j'utiliserais netshark pour regarder les en-têtes de session SMB au début des copies dans chaque direction et voir si quelque chose semble différent dans la configuration naru-> miyuki.
la source
Avez-vous essayé d'utiliser la téracopie? J'utilise cela comme remplacement standard pour la copie de Windows depuis plus d'un an maintenant, et il a montré des améliorations dans les vitesses de transfert :)
la source
Une sorte de cliché dans le noir mais ça pourrait aider.
ipconfig /flushdns
sur la CLI.la source
si cela est dû au changement du système d'exploitation, le problème réside certainement dans le système d'exploitation. vous devez essayer d'installer le dernier Service Pack Windows 7 et de maintenir Windows à jour avec les dernières mises à jour. Et espérer le meilleur
la source