Vérifiez la négociation du lien et les compteurs d'erreurs avant de modifier les paramètres de performance SMB, stockage ou NAS.
Une vitesse instable du NAS domestique se manifeste souvent par un transfert rapide qui chute soudainement, fait une pause, renégocie ou se rétablit après avoir reconnecté un câble. Le même symptôme peut provenir d'un décalage de duplex, d'un câble ou d'une prise marginale, d'un port de commutateur endommagé, d'erreurs signalées par le pilote, du comportement du contrôle de flux ou de blocages de stockage. Un diagnostic précis maintient un client, un fichier et un chemin constants tout en lisant les deux extrémités du lien Ethernet avant et après chaque changement contrôlé.
Enregistrez le modèle de défaillance avant de modifier le lien
Utilisez un grand fichier local et copiez-le dans les deux sens entre le même client et le NAS. Enregistrez la vitesse négociée, le débit dans le temps, la latence chargée et le moment exact où la vitesse chute ou le lien se réinitialise.
Les cas de la communauté Cisco décrivent le décalage de duplex comme produisant une connectivité lente et intermittente plutôt qu'un lien déconnecté de façon permanente. Cela rend la chronologie de la dégradation plus utile qu'un seul pic de référence.
Si la vitesse est constamment basse dès la première seconde, comparez la capacité réseau et les limites de stockage. Si elle commence rapide puis s'effondre, priorisez les erreurs de lien, le comportement thermique, la pression de la file d'attente, l'épuisement du cache ou un événement de renégociation de port.
Comparez la vitesse et le duplex aux deux extrémités
Consultez la vitesse active, le duplex et l'état d'auto-négociation sur l'interface NAS et le port de commutateur connecté. Ne comparez pas uniquement les valeurs configurées ; l'état opérationnel doit être identique aux deux extrémités.
Un décalage classique peut laisser un côté en duplex intégral et l'autre en semi-duplex, provoquant des collisions, des erreurs de réception, des retransmissions et un débit très variable. Même lorsque les liens multi-gigabits modernes nécessitent normalement l'auto-négociation, des réglages forcés ou du matériel intermédiaire ancien peuvent encore créer un résultat incohérent.
Revenez aux deux extrémités à l'auto-négociation prise en charge, sauf si la documentation matérielle exige une autre méthode. Reconnectez le lien et confirmez que les deux côtés rapportent la même vitesse et un état full-duplex avant de répéter le transfert.
Mesurez les erreurs physiques avant et après un transfert
Enregistrez les compteurs CRC, FCS, symboles, alignement, porteuse, réception, transmission, pertes et réinitialisations de lien sur le NAS et le commutateur. Réinitialisez les compteurs si possible, puis effectuez le même transfert volumineux assez longtemps pour reproduire l'instabilité.
Un rapport récent sur un NAS domestique a trouvé un lien 2,5 GbE devenu stable après le remplacement du câble ou de la prise. Ce résultat est plus probant que de supposer que le logiciel NAS a causé la variation de vitesse.
Une augmentation des erreurs CRC ou symboles indique un problème au niveau du câble, connecteur, transceiver ou port. Des pertes sans erreurs physiques pointent plutôt vers les files d'attente ou le traitement hôte, tandis qu'un chemin Ethernet propre avec un SMB lent oriente l'enquête vers le stockage et le travail applicatif.
Remplacez un composant physique à la fois
Commencez par un câble de raccordement court et connu bon, puis déplacez la connexion vers un autre port de commutateur sans changer le client, le NAS ou la charge de travail. Si le trajet inclut une prise murale, un coupleur, un panneau de brassage ou un adaptateur USB, réintroduisez chaque composant séparément.
Conservez la même durée de transfert et de test pour chaque substitution. Un composant est impliqué lorsque l'instabilité le suit ou disparaît systématiquement après son retrait, et non simplement parce qu'un essai est plus rapide.
Reprenez ou remplacez d'abord la plus petite pièce défaillante. Évitez de remplacer un câble encastré entier avant d'avoir prouvé que le câble de raccordement, la prise keystone, le port de commutateur ou l'adaptateur est le véritable point consommant la marge du lien.
Vérifiez que les erreurs signalées sont réelles
Les compteurs du pilote peuvent être trompeurs, surtout après des mises à jour du firmware ou du pilote. Comparez les erreurs du système d'exploitation avec les compteurs du commutateur, la perte de paquets, les retransmissions et la chronologie réelle du transfert avant de considérer un grand nombre comme preuve d'une défaillance du câble.
Un cas de la communauté Intel a documenté un faux signalement d'erreurs de réception qui ne représentait pas une perte réelle de paquets en production. La signification des compteurs doit donc être vérifiée selon la version de l'adaptateur et du pilote.
Si un seul compteur logiciel augmente tandis que le commutateur pair, la capture de paquets et la charge de travail restent propres, mettez à jour ou revenez à une version antérieure du pilote avant de remplacer le matériel. Si les compteurs indépendants et le transfert échouent ensemble, continuez à traiter l'événement comme une vraie défaillance de lien.
Séparez la stabilité Ethernet de la vitesse de stockage NAS
Effectuez un test réseau mémoire-à-mémoire sur le même chemin, puis comparez-le avec le transfert SMB de gros fichiers. Cela élimine les écritures disque, l'allocation du système de fichiers, les instantanés, la parité, le chiffrement et le scan applicatif du premier résultat.
L'explication ZimaSpace de la façon dont la perte de paquets réduit le débit utile du NAS aide à interpréter pourquoi l'interface peut rester connectée alors que la vitesse applicative oscille.
La réparation est complète uniquement lorsque le test réseau seul et la charge SMB originale se répètent avec une vitesse stable, des compteurs physiques propres, un duplex correspondant et aucune renégociation de lien. Si le test réseau est propre mais que SMB reste instable, cessez de changer les câbles et poursuivez avec les tests de stockage, CPU et charge de travail fichier.
Assistance et conseils
Plus à lire

Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...

Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...

Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...

