Vitesses de réseau gigabit lentes inexpliquées

18

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.

Joshua
la source
1
avez-vous essayé un outil comme iperf (google pour iperf win32) pour mesurer la bande passante disponible? si iperf donne des vitesses raisonnables peut-être sa nouvelle invention drm: /. j'en doute - mais ça vaut le coup de vérifier sinon revérifiez s'il n'y a pas de mésappariement duplex.
pQd
Avez-vous essayé quelque chose comme pscp sur un serveur à proximité pour voir quelle vitesse vous obtenez avec cela?
chris
1
Avez-vous essayé de connecter ensemble le serveur et l'ordinateur portable afin qu'il n'y ait pas de commutateur entre eux?
Joseph
Amen à ce que @Joseph a dit. Veuillez essayer d'éliminer l'interrupteur de l'équation.
Jeremy Visser

Réponses:

5

Essayez de désactiver la fonction de réglage automatique de Windows.

Dans une fenêtre CMD:

netsh interface tcp set global autotuning=disabled 

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:

netsh interface tcp set global autotuning=normal
Tim Kennedy
la source
3

Cela semble être un gros problème avec Windows 7. Plusieurs joueurs se sont plaints de ce problème.

  1. À partir d'une invite de commande (généralement dans Tous les programmes -> Accessoires -> Invite de commandes) exécutez «regedit»
  2. Accédez à HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ Parameters \ Interfaces
  3. Parcourez les éléments sous les interfaces jusqu'à ce que vous en trouviez un qui possède une entrée IPAddress correspondant à l'interface réseau que vous souhaitez affecter (généralement les adresses IP LAN commencent par 192.168 ou 10.0); notez que si votre adresse IP est automatiquement attribuée par un serveur DHCP, vous devrez peut-être rechercher un DhcpIPAddress correspondant au lieu de IPAddress
  4. Faites un clic droit sur l'interface et sélectionnez Nouveau> Valeur DWORD (32 bits), nommez-le «TcpAckFrequency»
  5. Cliquez avec le bouton droit sur la nouvelle valeur TcpAckFrequency et sélectionnez Modifier, entrez «1» (le bouton radio hexadécimal doit être sélectionné)
  6. Faites un clic droit sur l'interface et sélectionnez Nouveau> Valeur DWORD (32 bits), nommez-le «TCPNoDelay» (notez que TCP est tout en majuscules cette fois - c'est intentionnel)
  7. Cliquez avec le bouton droit sur la nouvelle valeur TCPNoDelay et sélectionnez Modifier, entrez «1» (le bouton radio hexadécimal doit être sélectionné)
  8. Vérifiez que TcpAckFrequency et TCPNoDelay apparaissent désormais dans la liste des propriétés de l'adaptateur avec les types REG_DWORD et les valeurs 0 × 00000001
  9. Quittez regedit et redémarrez (le redémarrage est nécessaire pour que les modifications prennent effet!)
    1. Jouez à un jeu et profitez de votre nouveau ping faible

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

JJ01
la source
1
tracert utilise ICMP, pas TCP. Ces clés sont pour TCP, donc elles ne changent rien pour ICMP. Je ne sais pas pourquoi vous avez vu un meilleur temps de réponse grâce à Tracert
Mathieu Chateau
Eh bien, je suis allé de l'avant et j'ai essayé et cela semble toujours être le même. Je mets à jour la question d'origine avec plus d'informations et de choses que j'ai essayées.
Joshua
2
Matthieu, il n'a pas dit avoir vu un meilleur temps d'un tracert. Il a déclaré que la latence dans le jeu devient équivalente à un tracert, ce qui signifie que la latence observée dans le trafic TCP est similaire à celle du trafic ICMP, qui fonctionnait normalement.
MDMarra
3

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.

Mat
la source
1

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
1

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.

Ben Campbell
la source
1

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é.

Dom
la source
J'ai été brûlé par ça aussi ...
Ben Campbell
1

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

  • vérification de la taille des blocs des partitions sur le disque dur des ordinateurs portables (les petites tailles de bloc peuvent entraîner un mauvais temps de recherche d'espace libre lors de la tentative de transfert d'un seul gros fichier (ou ainsi))
  • vérification de toute politique de pare-feu qui vérifie l'écriture sur disque des paquets entrants
  • vérifier n'importe quel moniteur d'activité de fichier (cela ne devrait pas vous inquiéter car vous désinstallez l'antivirus) (comme vous le savez, avast fait des vérifications de fichiers en direct et cela ralentit un peu le transfert réseau ..)
  • défragmentation de la partition cible (encore une fois sur la recherche d'espace libre)

D'autres sont suggérées et ne semblent pas aider:

  • réglage automatique
  • niveau duplex
  • câbles ...

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 ...

L'extraterrestre
la source
1

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.

Gi Cakov
la source
0

Par tout, je suppose que vous avez défini les cartes réseau en duplex intégral, 100 Mo et non en mode automatique?

chris
la source
1
+1 pour "pas automatique" :)
dimitri.p
Oui, j'ai essayé toutes les variantes prises en charge par ma carte ... 10 moitié, 10 pleine, 100 moitié, 100 pleine et 1000 pleine. Aucun de ceux qui l'ont affecté en aucune façon et selon les commutateurs qu'ils négocient à 1000 pleins.
Joshua
10
Ne faites jamais cela si le commutateur n'est pas gérable. Si vous êtes forcé en duplex intégral d'un côté mais automatique de l'autre côté, l'autre côté devient semi-duplex. Ensuite, vous commencez à perdre des paquets (beaucoup ...). Les commutateurs que vous ne pouvez pas gérer sont automatiques. Gardez auto sur votre serveur et vérifiez que l'interface a négocié le duplex intégral. Vérifiez également les erreurs d'interface.
Mathieu Chateau
4
-1 pour "pas automatique". Vous avez besoin de la même configuration aux deux extrémités (commutateur et NIC), y compris la négociation automatique.
dunxd
5
Je suis curieux, avez-vous essayé de retirer le commutateur de l'équation et de faire passer un câble croisé du "serveur" directement au "portable"?
SpacemanSpiff
0

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.

William Hilsum
la source
Haha, ouais, c'était en fait la première chose que j'essayais. En ce moment, je suis de retour sur les pilotes Windows 7 intégrés, mais j'ai également essayé les derniers nvidia. Les seuls pilotes que je n'ai pas essayés sont ceux de Windows 7 beta ou Vista.
Joshua
Essayez ceux de Vista et voyez comment cela se déroule. J'ai eu plusieurs problèmes mineurs qui ont été corrigés dans les mises à jour pour Win7 maintenant; J'ai corrigé manuellement en installant les pilotes Vista pour le matériel.
David Rickman
0

Je soupçonne que c'est quelque chose sur le chemin du serveur à l'ordinateur portable, par exemple:

  • Port de commutateur patché sur ordinateur portable
  • Câblage Ethernet ou connexions entre le commutateur et l'ordinateur portable

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).

Skyhawk
la source
0
  1. 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"?

  2. 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?

  3. 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.

marque
la source
0

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 :)

Administrateur de Bahreïn
la source
-1

Une sorte de cliché dans le noir mais ça pourrait aider.

  • Désactivez «Compression différentielle à distance» dans le Panneau de configuration - Programmes et fonctionnalités - Activez ou désactivez les fonctionnalités Windows.
  • Supprimez IPv6 des propriétés du réseau. Utilisez-vous IPv6 dans votre LAN? Sinon, désactivez-le.
  • Vider le cache DNS avec ipconfig /flushdnssur la CLI.
duenni
la source
-1

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

Farhan
la source