Verifique la negociación del enlace y los contadores de errores antes de cambiar la configuración de rendimiento de SMB, almacenamiento o NAS.
La velocidad inestable del NAS doméstico a menudo se presenta como una transferencia rápida que de repente cae, se pausa, renegocia o se recupera después de reconectar un cable. El mismo síntoma puede deberse a una incompatibilidad de dúplex, un cable o conector marginal, un puerto de switch dañado, errores reportados por el controlador, comportamiento de control de flujo o bloqueos de almacenamiento. Un diagnóstico limpio mantiene un cliente, un archivo y una ruta constantes mientras se leen ambos extremos del enlace Ethernet antes y después de cada cambio controlado.
Registre el Patrón de Fallos Antes de Cambiar el Enlace
Use un archivo local grande y cópielo en ambas direcciones entre el mismo cliente y el NAS. Registre la velocidad negociada, el rendimiento a lo largo del tiempo, la latencia cargada y el momento exacto en que la velocidad cae o el enlace se reinicia.
Los casos de la comunidad Cisco describen la incompatibilidad de dúplex como causante de conectividad lenta e intermitente en lugar de un enlace permanentemente desconectado. Eso hace que la línea de tiempo de degradación sea más útil que un solo punto máximo de referencia.
Si la velocidad es consistentemente baja desde el primer segundo, compare la capacidad de la red y los límites de almacenamiento. Si comienza rápido y luego colapsa, priorice errores de enlace, comportamiento térmico, presión de colas, agotamiento de caché o un evento de renegociación del puerto.
Compare la Velocidad y el Dúplex en Ambos Extremos
Lea la velocidad activa, el dúplex y el estado de auto-negociación en la interfaz NAS y en el puerto del switch conectado. No compare solo los valores configurados; el estado operativo debe coincidir en ambos extremos.
Una incompatibilidad clásica puede dejar un lado en dúplex completo y el otro en medio dúplex, causando colisiones, errores de recepción, retransmisiones y un rendimiento altamente variable. Incluso cuando los enlaces multi-gigabit modernos normalmente requieren auto-negociación, configuraciones forzadas o hardware intermedio antiguo aún pueden crear un resultado inconsistente.
Devuelva ambos extremos a la auto-negociación soportada a menos que la documentación del hardware requiera otro método. Reconecte el enlace y confirme que ambos lados reportan la misma velocidad y estado de dúplex completo antes de repetir la transferencia.
Mida los Errores Físicos Antes y Después de Una Transferencia
Registre los contadores CRC, FCS, símbolo, alineación, portadora, recepción, transmisión, caída y reinicio de enlace en el NAS y el switch. Restablezca los contadores cuando sea posible, luego ejecute la misma transferencia grande el tiempo suficiente para reproducir la inestabilidad.
Un informe reciente de NAS doméstico encontró un enlace 2.5GbE que se volvió estable después de reemplazar el cable o conector. Ese resultado es más sólido que asumir que el software del NAS causó el cambio de velocidad.
El aumento de errores CRC o de símbolo apunta hacia el cable, conector, transceptor o puerto. Las caídas sin errores físicos apuntan más hacia colas o procesamiento del host, mientras que un camino Ethernet limpio con cambios lentos en SMB desplaza la investigación hacia el almacenamiento y el trabajo de la aplicación.
Reemplace Un Componente Físico a la Vez
Comience con un cable patch corto y conocido como bueno, luego mueva la conexión a otro puerto del switch sin cambiar el cliente, NAS o carga de trabajo. Si la ruta incluye un conector de pared, acoplador, panel de parcheo o adaptador USB, reintroduzca cada componente por separado.
Mantenga la misma transferencia y duración de prueba para cada sustitución. Un componente está implicado cuando la inestabilidad lo sigue o desaparece consistentemente después de ser removido, no solo porque una ejecución sea más rápida.
Retermine o reemplace primero la parte más pequeña que falla. Evite reemplazar un cable completo dentro de la pared antes de probar que el cable patch, keystone, puerto del switch o adaptador es el punto real que consume el margen del enlace.
Verifique Que los Errores Reportados Sean Reales
Los contadores del controlador pueden ser engañosos, especialmente después de actualizaciones de firmware o controlador. Compare los errores del sistema operativo con los contadores del switch, pérdida de paquetes, retransmisiones y la línea de tiempo real de la transferencia antes de tratar un gran número como prueba de fallo del cable.
Un caso de la comunidad Intel documentó reportes falsos de errores de recepción que no representaban pérdida real de paquetes en producción. Por lo tanto, el significado del contador debe verificarse según la versión del adaptador y controlador.
Si solo un contador de software aumenta mientras el switch par, la captura de paquetes y la carga de trabajo permanecen limpias, actualice o retroceda el controlador antes de reemplazar hardware. Si los contadores independientes y la transferencia fallan juntos, continúe tratando el evento como una falla real del enlace.
Separe la Estabilidad de Ethernet de la Velocidad de Almacenamiento NAS
Ejecute una prueba de red de memoria a memoria sobre la misma ruta, luego compárela con la transferencia SMB de archivo grande. Esto elimina las escrituras en disco, asignación del sistema de archivos, instantáneas, paridad, cifrado y escaneo de aplicaciones del primer resultado.
La explicación de ZimaSpace sobre cómo la pérdida de paquetes reduce el rendimiento útil del NAS ayuda a interpretar por qué la interfaz puede permanecer conectada mientras la velocidad de la aplicación oscila.
La reparación está completa solo cuando la prueba solo de red y la carga de trabajo SMB original se repiten con velocidad estable, contadores físicos limpios, dúplex coincidente y sin renegociación del enlace. Si la prueba de red está limpia pero SMB sigue inestable, deje de cambiar cables y continúe con pruebas de almacenamiento, CPU y carga de trabajo de archivos.
Soporte y Consejos
Más para leer

¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...

Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...

Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...

