☰

Version corta

tag-icon • tag-icon ethernet throughput
Version corta

Version corta

Mi red doméstica es puramente gigabit con dispositivos que admiten tramas gigantes de hasta al menos ~9000 bytes. Aumentar la configuración de trama gigante MTU en Synology a 6000 (bytes) aumenta el rendimiento (escritura de 810 Mbps y lectura de 945 Mbps). Establecer el valor en 7000 destruye sólo el rendimiento de lectura (que disminuye hasta 4 Mbps); el rendimiento de escritura se mantiene rápido.

Esto es inesperado porque la mayoría de los problemas de tramas gigantes no tienen una direccionalidad asociada y normalmente son de todo o nada (los paquetes se descartan en un conmutador sin importar de dónde vengan). No parece habercualquierLa fragmentación de IP continúa, pero la capa TCP está realmente descontenta. ¿Qué podría causar este comportamiento asimétrico/inconsistente y cómo puedo solucionarlo para que admita la MTU completa de 9000 bytes que se supone que admite todo mi equipo?

Versión larga

Estas son mis notas editadas que tomé mientras intentaba resolver esto.

Cliente

Controlador de la familia Realtek PCIe GBE RTL8167
Jumbo Frame: 9KB MTU

$ netsh interface ipv4 show subinterfaces
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  9198                1   32501506   11275394  Local Area Connection

(parece que 9198 no incluye el encabezado Ethernet de 14 bytes)

$ ping -l 1500 -f 192.168.1.84

(observado con Wireshark ejecutándose en el Cliente; todos los tamaños son tamaños de bytes de cable)
[9213, ∞] no enviado por el host (requeriría fragmentación)
[9019, 9212] enviado pero sin respuesta
[9015, 9018] respuesta IP fragmentada
[42, 9014 ] IP no fragmentada
[0, 41] ? (no se puede generar ya que encabezados eth+IP+ICMP = 14+20+8 = 42 bytes)

Enrutador (parte del interruptor)

Asus RT-AC68U - Firmware 3.0.0.4.378_4585
Habilitar trama gigante: "Habilitar"
No puedo determinar qué tamaño de trama gigante realmente admite, parece ser al menos 9000

Fragmenta las solicitudes de ping del Cliente directamente en 1514 bytes (pero hacer ping al enrutador podría estar activando el comportamiento del enrutador WAN en lugar del comportamiento del conmutador LAN).

Conmutador no administrado

TP-LINK TL-SG1008D
Jumbo Frames (hojas de especificaciones): 9 KB (su sitio web dice 15 KB pero parece un dispositivo diferente)

Servidor

Synology DS1815+ - DSM 5.2-5565 Actualización 1
Marco gigante: 9000

Paquetes de lectura de archivos de Synology al Cliente
Tamaño: la mayoría son 9014 bytes (en ambas direcciones)
Banderas IP: No fragmentar
Wireshark descubierto: retransmisión espuria de TCP, segmento anterior de TCP no capturado, TCP fuera de servicio, retransmisión rápida de TCP y paquetes
SMB2 normales (9014 bytes) Longitud de lectura de la respuesta de lectura de paquetes a través del protocolo NetBIOS: 65,536 (~8 segmentos TCP)

$ ifconfig
bond0     Link encap:Ethernet  HWaddr --:FF
          inet addr:192.168.1.84  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:85 dropped:0 overruns:0 frame:85
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:237 GiB  TX bytes:117 GiB

eth2      Link encap:Ethernet  HWaddr --:00
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:19 dropped:0 overruns:0 frame:19
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:236 GiB  TX bytes:83 GiB

eth3      Link encap:Ethernet  HWaddr --FF
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:66 dropped:0 overruns:0 frame:66
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1 GiB  TX bytes:33 GiB

eth2 y eth3 están unidos mediante equilibrio de carga adaptativo (sin soporte para conmutadores)

$ ping -c 5 -s 1500 192.168.1.82

(observado con Wireshark ejecutándose en el Cliente; todos los tamaños son tamaños de bytes de cable)
[9019, ∞] solicitud enviada, respuesta enviada, respuesta no recibida
[9015, 9018] solicitud de IP fragmentada (probablemente fragmentada por Synology, el ping de Busybox no tiene un opción sin fragmentos, por lo que es difícil saberlo)
[60, 9014] IP no fragmentada
[0, 59] ? (no se puede generar porque el ping de Busybox pone un mínimo de 18 bytes más los encabezados de 42 bytes)

Datos varios

  • Cambiar la MTU del cliente a 8 KB no ayudó
  • La velocidad de lectura del servidor cae por un precipicio al cambiar la MTU del servidor de 6000 (excelente, 945 Mbps) a 7000 (terrible, 4 Mbps)
  • La velocidad de escritura del servidor básicamente no se ve afectada en ninguna configuración de MTU del servidor (siempre entre 700 y 825 Mbps)
  • Synology tiene una red unida (2 de los 4 puertos)
  • Los cables son todos Cat6 o Cat5e.

Respuesta1

Actualizar el firmware

En mi experiencia, Synology soluciona muchos problemas en cada versión de firmware y la que estás ejecutando tiene casi cuatro años. No he leído las notas de la versión, pero parece que hay muchas posibilidades de que se haya solucionado un error de trama Jumbo desde entonces.

Prueba con una conexión directa

Conecte su máquina de prueba directamente a Synology (asigne IP estáticas en la misma subred) con nuevos cables de conexión y vuelva a ejecutar sus pruebas. Esto eliminará el cableado y los interruptores, así como cualquier otro problema de configuración y equipo. Si el problema persiste, ejecute sus pruebas con otra computadora. Si aún permanece, sin duda es el NAS.

Si el problema desaparece durante la prueba de conexión directa, intente reemplazar primero el interruptor y luego el cableado. No ha mostrado las conexiones, así que supongo que solo el TPLINK entre la máquina de prueba y el NAS.

información relacionada