Guía de configuración avanzada de NIC en Windows — RSS/LSO/EEE/Wake on LAN

La pestaña [Advanced] del NIC en Windows presenta bastantes términos poco familiares. Jumbo Packet, Large Send Offload, Interrupt Moderation, Receive Side Scaling, Flow Control, Energy Efficient Ethernet. Solo con ver los nombres dan ganas de habilitarlos todos, pero en la práctica la respuesta correcta depende de qué se quiera priorizar.

• ¿Quiere aumentar el throughput de transferencias grandes?
• ¿Quiere reducir la latencia de paquetes pequeños?
• ¿Quiere reducir el uso de CPU?
• ¿Quiere estabilizar la reanudación desde suspensión o Wake on LAN?
• ¿Quiere aislar problemas de compatibilidad con el controlador o el switch?

Si esto queda sin definir y se opta por «de momento activarlo todo», «de momento Jumbo 9014» o «como va lento, lo fijo en 1 Gbps Full», es bastante normal que termine en un problema.

En este artículo organizamos, principalmente para adaptadores Ethernet cableados de Windows 10 / 11 / Windows Server, la forma de pensar al tocar la configuración avanzada del NIC en el trabajo diario. Escribimos de manera que se pueda ver de un vistazo el significado de cada ajuste, qué suele ocurrir al subirlo, bajarlo, habilitarlo o deshabilitarlo, y en qué situaciones conviene tocarlo.

Además, el nombre mostrado y los valores disponibles del NIC varían bastante según el fabricante y el controlador. A veces Jumbo Packet aparece como Jumbo Frames, Receive Buffers como Receive Descriptors, o Priority & VLAN como Packet Priority & VLAN. En este artículo agrupamos los ajustes con un significado cercano.

Cómo usar este artículo

Como hay 14 capítulos y es largo, primero dejamos una guía de navegación. No hace falta leerlo todo.

Creemos que la forma de lectura más habitual es «partir de un síntoma, ir al capítulo 11 → el capítulo del ajuste correspondiente → volver al capítulo 10».

Mini glosario de siglas

Para poder leer contrastando con la pantalla de configuración, aquí resumimos las siglas que aparecen en este artículo.

1. Primero, la conclusión

Antes que nada, dejamos por delante solo la conclusión que difícilmente falla en el trabajo diario.

• Speed & Duplex debe estar básicamente en Auto. Ante un problema en el que la velocidad cae a 100 Mbps, ir directamente a fijar 1.0 Gbps Full Duplex es el último recurso.
• Checksum Offload / RSS / LSO / RSC deben estar, por norma general, habilitados o en su valor predeterminado. Deshabilitarlos todos sin criterio tiende a consumir CPU de forma innecesaria.
• Jumbo Packet se usa solo cuando queda alineado de extremo a extremo (end-to-end). Poner solo el NIC en 9014 mientras la ruta intermedia sigue en 1500 es una trampa.
• Interrupt Moderation es un tira y afloja entre throughput y latencia. Ponerlo más alto alivia la CPU, pero aumenta la latencia.
• Flow Control puede ayudar a reducir las pérdidas de paquetes (drops), pero también puede propagar la congestión.
• EEE / Green Ethernet / Selective Suspend son ajustes de ahorro de energía, no ajustes para ganar velocidad.
• VMQ / SR-IOV están orientados a hosts Hyper-V y no son ninguna fórmula mágica para acelerar un PC de escritorio normal.
• Wake on Pattern Match tiende a provocar despertares no deseados, así que si solo se necesita Wake on LAN es más seguro limitarse a Magic Packet.
• Es mejor no tocar hoy en día elementos antiguos como TCP Chimney Offload.

En resumen, la configuración avanzada del NIC no es «un lugar donde habilitar todo lo que parezca potente». Es un lugar donde se decide cuál de estos objetivos se persigue: throughput, latencia, CPU, consumo de energía o compatibilidad, y se toca un elemento a la vez.

2. Dónde ver la configuración

2.1 Verla desde la GUI

Desde Conexiones de red

1. Ejecute ncpa.cpl
2. Haga clic derecho sobre el adaptador en cuestión
3. Propiedades → Configurar
4. Pestaña Opciones avanzadas (Advanced)

Desde el Administrador de dispositivos

1. Administrador de dispositivos
2. Adaptadores de red
3. Haga clic derecho sobre el NIC en cuestión → Propiedades
4. Pestaña Opciones avanzadas

Los elementos que aparecen aquí son los protagonistas de este artículo. Sin embargo, la configuración de la pestaña Power Management también influye bastante en la práctica, así que la trataremos en la segunda mitad.

2.2 Verla desde PowerShell

Con PowerShell resulta más fácil ver los valores actuales en forma de listado y hacer una copia de seguridad antes de cambiar nada.

Get-NetAdapter

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword, RegistryValue -Auto

Según el NIC, RegistryKeyword puede tener un nombre estandarizado y verse como *RSS, *VMQ, *SRIOV o *EEE. Sin embargo, DisplayName y DisplayValue dependen del controlador. Al escribir un script de cambio, es más seguro ver primero el listado en el equipo real.

3. Principios generales antes de tocar nada

Antes de tocar la configuración del NIC, si se pasa por alto esto casi siempre se termina en un atolladero.

3.1 Primero decida «qué quiere mejorar»

Aunque se diga «la red va lenta» en ambos casos, el contenido puede ser completamente distinto.

• Copiar archivos grandes es lento → throughput, RSS, RSC, LSO, Jumbo, buffers
• Los request/response pequeños van con retraso → Interrupt Moderation, RSC, EEE, profundidad de cola
• La CPU está alta → offloads, RSS, RSC, interrupciones
• Algo falla tras reanudar desde suspensión → Selective Suspend, Power Management, WoL
• Se corta de vez en cuando / pasa a 100 Mbps → cable, equipo remoto, Speed & Duplex, EEE, controlador

Si se toca el mismo ajuste para objetivos distintos, en lugar de mejorar la situación se puede empeorar.

3.2 Primero sospeche de la capa física y del equipo remoto

Es normal que existan problemas que la configuración del NIC no puede resolver.

• Cable defectuoso
• Incompatibilidad con switch / router / dock
• Firmware antiguo
• Falta de energía en un NIC USB
• Errores del lado del puerto
• Pérdida de paquetes y retransmisiones

En particular, ante una caída a 100 Mbps, un enlace que hace flapping o fallos solo en transferencias grandes, es más rápido revisar primero la capa física y el equipo remoto antes que la configuración.

3.3 Cambie un solo elemento por vez

Si cambia Jumbo, LSO, RSC, RSS y EEE todos a la vez, dejará de saber cuál de ellos tuvo efecto. La norma básica es anotar la configuración previa al cambio, modificar un elemento a la vez y medir el cambio resultante.

3.4 Decida qué va a medir

Como mínimo, conviene observar lo siguiente.

• Velocidad de enlace (1G / 2.5G / 10G, etc.)
• Throughput
• Latencia
• Uso de CPU
• Estadísticas del NIC (drop / error / falta de buffer)
• Estabilidad de la reanudación desde suspensión

Un cambio de configuración es más sólido si se evalúa con números y no solo con la sensación subjetiva.

4. Tabla resumen de los ajustes principales

Antes que nada, dejamos una tabla en la que se puede ver de un vistazo el rol de cada ajuste.

5. Ajustes relacionados con el enlace y el tamaño de trama

5.1 Speed & Duplex

Este es un ajuste relacionado con la negociación de la velocidad de enlace y el modo dúplex completo/medio. Su nombre visible puede ser Speed & Duplex, Link Speed, Link Speed & Duplex, entre otros.

Qué hace este ajuste

En Ethernet, el NIC y el equipo remoto acuerdan a qué velocidad y en qué modo dúplex se van a comunicar.

• Auto Negotiation
• 100 Mbps Full Duplex
• 1.0 Gbps Full Duplex
• 2.5 Gbps Full Duplex
• 10 Gbps Full Duplex

Suelen aparecer opciones como estas.

Qué cambia al modificarlo

Ponerlo en Auto

• Entre equipos modernos, esto suele ser lo más estable
• En 1000BASE-T o superior, en muchos casos se da por hecho el uso de Auto
• Se integra mejor con la negociación de EEE y de master/slave

Fijarlo manualmente

• Puede mejorar la compatibilidad con switches antiguos o equipos remotos que están forzados a un valor fijo
• Sin embargo, un estado en el que solo un lado está fijado y el otro en Auto es fuente de problemas
• Si se produce un duplex mismatch, provoca caída de velocidad, retransmisiones y latencias anómalas

Política básica en la práctica

Normalmente basta con dejarlo en Auto. «Como no llega a 1 Gbps, lo fijo en 1 Gbps Full» suena contundente, pero a menudo se equivoca de causa.

5.2 Jumbo Packet / Jumbo Frames

Este es un ajuste que usa tramas Ethernet mayores que el estándar. Su nombre visible puede ser Jumbo Packet, Jumbo Frames, Jumbo Packet Size, entre otros.

Qué hace este ajuste

El Ethernet habitual suele funcionar dando por hecho un MTU de 1500. Al habilitar Jumbo Frame, se puede usar tramas grandes de alrededor de 9000 bytes.

Sin embargo, aquí hay muchas trampas de nomenclatura.

• El controlador puede mostrar el tamaño de trama, como 9014 Bytes
• El SO o las herramientas pueden verlo desde la perspectiva L3, como MTU 9000
• El switch puede contarlo incluyendo el CRC o la etiqueta VLAN

Si se comparan los números uno al lado del otro sin más, es bastante fácil caer en la trampa.

Qué cambia al modificarlo

Aumentarlo / habilitarlo

• Al enviar datos grandes, disminuye la cantidad de paquetes
• Disminuye el número de veces que se procesa la cabecera
• Tiende a bajar el uso de CPU
• Por otro lado, el tiempo de ocupación por paquete se alarga
• Si algún punto de la ruta no lo admite, provoca drops o fragmentación

Volver al estándar / deshabilitarlo

• Es lo más compatible
• Aumenta la cantidad de paquetes
• En transferencias grandes tiende a aumentar la CPU y el overhead de cabecera

Política básica en la práctica

Jumbo solo tiene sentido cuando está alineado de extremo a extremo (end-to-end).

• Su propio NIC
• El NIC del equipo remoto
• El switch intermedio
• Si hay VLAN o un switch virtual de por medio, su overhead

Si cualquiera de estos se queda en 1500, lejos de obtener beneficio, se convierte en fuente de problemas.

5.3 Gigabit Master / Slave Mode

En 1000BASE-T, este es un ajuste relacionado con quién actúa como master y quién como slave para liderar el reloj. En un PC normal, prácticamente no se toca.

Política básica

• Auto es lo básico
• Evalúelo únicamente ante problemas de calidad de enlace con un equipo remoto antiguo específico
• A menos que el fabricante lo indique, no lo trate como una perilla de ajuste de rendimiento

5.4 Wait for Link y ajustes relacionados con el estado del enlace

Ajustes como Wait for Link determinan si el controlador espera a que la auto negotiation tenga éxito antes de reportar el estado del enlace. Log Link State Event es un ajuste de diagnóstico que registra los eventos de link up/down en el registro de eventos.

Política básica

• En un PC normal basta con dejar el valor predeterminado
• Tiene sentido más para el diagnóstico del comportamiento al arrancar o del failover que para el rendimiento en sí
• No es un elemento que se toque en primera instancia

6. Ajustes que afectan la carga de CPU, el throughput y la latencia

Este es el bloque que más parece «tener efecto». En efecto suele tenerlo, pero la dirección en la que actúa se divide claramente.

6.1 Checksum Offload

Es un ajuste que delega en el NIC el cálculo del checksum de IP / TCP / UDP.

Política básica

• Habilitado por norma general
• Manténgalo si quiere reducir la CPU
• Un error de checksum en una captura suele ser solo la forma en que se ve el offload
• Está bien deshabilitarlo temporalmente para diagnosticar compatibilidad

6.2 Large Send Offload (LSO) / TSO / Offload TCP Segmentation

Es un ajuste por el cual el NIC divide en tramas pequeñas los datos de envío TCP de gran tamaño.

En qué influye

• Throughput en escenarios con mucho envío
• Reducción del uso de CPU
• Envíos continuos de tamaño considerable

Política básica

• Normalmente, habilitado
• Si sospecha de compatibilidad con una aplicación o controlador concreto, deshabilítelo temporalmente para comparar la diferencia

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

Es un ajuste que agrupa en el lado de recepción varios segmentos TCP.

En qué influye

• Throughput del lado de recepción
• Reducción del uso de CPU

Puntos a tener en cuenta

• Puede resultar desfavorable en baja latencia o en observación a nivel de paquete
• La interpretación de las capturas y de las mediciones de tiempo cambia ligeramente

Política básica

• Habilitado si quiere obtener throughput de recepción
• Es un candidato a evaluar si le importa la latencia de request/response pequeños

6.4 Offloads recientes del lado UDP (USO / URO)

En NIC y sistemas operativos recientes, también pueden aparecer offloads nuevos para el envío/recepción de UDP.

Política básica

• Aunque aparezcan, en principio no se aparte del valor predeterminado
• Mídalos solo cuando el controlador sea suficientemente reciente y la carga de trabajo objetivo esté clara
• No los toque forzosamente durante un diagnóstico de problemas

6.5 Receive Side Scaling (RSS)

Es un ajuste que distribuye el procesamiento de recepción entre varias CPU. Es bastante importante en entornos multi-core.

Política básica

• Habilitado por norma en entornos multi-core
• Revíselo primero ante síntomas de que todo se concentra en una sola CPU
• Suele ser protagonista también como paso previo a Hyper-V o a escenarios de alto throughput

6.6 RSS Queues / RSS Processors / RSS Profile

Son elementos que determinan el grado de paralelismo de RSS.

Política básica

• Empiece por el valor predeterminado
• Auméntelos después de observar el uso de CPU o el desequilibrio de colas
• Subirlos al máximo sin criterio puede aumentar la carga de interrupciones y de DPC

6.7 Interrupt Moderation / Interrupt Moderation Rate

Es un ajuste que reduce la frecuencia de interrupciones, intercambiando carga de CPU por latencia.

Tendencia

• Alto / Adaptive → Tiende a aliviar la CPU, pero tiende a aumentar la latencia
• Bajo / Off → Tiende a bajar la latencia, pero tiende a subir la carga de CPU / DPC

Política básica

• Punto de partida: predeterminado / Adaptive
• Si le preocupa el jitter en paquetes pequeños, evalúe Low / Off
• En transferencias grandes, el valor predeterminado suele ser lo más sencillo

6.8 Receive Buffers / Receive Descriptors y Transmit Buffers / Transmit Descriptors

Es un ajuste que cambia la profundidad del anillo / buffer.

Dirección en la que influye

• Resistencia a ráfagas
• Throughput sostenido
• Evitar drops

Efectos secundarios

• Aumenta el consumo de memoria
• La cola se vuelve más profunda y puede aumentar la latencia de espera

Política básica

• Auméntelos solo cuando observe drops o falta de buffer
• Evite ponerlos al máximo sin un motivo claro

6.9 Flow Control

Es un ajuste relacionado con el envío/recepción de tramas pause 802.3x.

Política básica

• Es un candidato si quiere reducir los drops
• Sin embargo, la pausa también puede propagar otra congestión
• En escenarios de baja latencia, obsérvelo con cautela
• Piénselo junto con el diseño de red completo

7. Ajustes relacionados con VLAN, QoS y virtualización

7.1 Priority & VLAN / Packet Priority & VLAN / NDIS QoS

Es el bloque que trata VLAN 802.1Q y Priority 802.1p.

Política básica

• Préstele atención solo cuando de verdad use VLAN / QoS
• En un entorno de puerto de acceso (access port) simple, basta con el valor predeterminado
• Tenga cuidado con las configuraciones en las que se añaden etiquetas automáticamente, porque dificultan el diagnóstico

7.2 VMQ / VMMQ / SR-IOV

Este es un ajuste que cobra sentido en hosts Hyper-V o infraestructuras de virtualización.

Política básica

• No lo trate como un ajuste de tuning de escritorio normal
• En un host Hyper-V, evalúelo junto con la configuración del vSwitch, la asignación de colas y la configuración del lado del invitado
• Difícilmente se obtiene la respuesta correcta mirando solo un lado

7.3 RDMA / DCB / PFC son otro mundo

Este ámbito, que incluye SMB Direct y Ethernet sin pérdidas (lossless), es bastante otro mundo.

Política básica

• Considérelo por separado del ajuste habitual de escritorio en 1GbE / 2.5GbE
• Consulte a la vez la documentación del fabricante y el diseño del lado del switch

8. Ajustes relacionados con el ahorro de energía, la suspensión y Wake on LAN

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

Es un ajuste que reduce el consumo cuando el enlace está inactivo (idle), con fines de ahorro de energía.

Cómo interpretarlo

• No es un ajuste para ganar velocidad
• Sí influye en el consumo de energía
• Según el equipo remoto o las condiciones del cable, es un candidato a evaluar ante inestabilidad de enlace o downshift a 100 Mbps

Política básica

• Para uso general, basta con el valor predeterminado
• Ante inestabilidad de enlace, downshift a 100 Mbps o cuando prima la baja latencia, es el primer candidato a evaluar

8.2 Selective Suspend / Device Sleep / control del enlace durante el Standby

Dicho de forma sencilla, es un ajuste sobre hasta qué punto se deja «dormir» al NIC durante el estado idle o la suspensión.

Política básica

• En portátiles, empiece por el valor predeterminado
• Si hay problemas de reanudación, sospeche de esto primero
• En PC de control de equipos o en operación 24/7, a veces resulta más claro deshabilitarlo directamente

8.3 Wake on Magic Packet / Wake on Pattern Match

Este es un ajuste para despertar por red un PC que está en suspensión.

Política básica

• Si necesita Wake on LAN, habilite Magic Packet
• Si no lo necesita, deshabilítelo
• Pattern Match, solo cuando la necesidad esté clara

Es normal que, aunque se habilite solo en el NIC, el equipo no despierte. Revise también el lado del BIOS/UEFI y la pestaña Power Management.

8.4 ARP Offload / NS Offload

Es un ajuste por el cual el NIC se hace cargo de respuestas mínimas incluso durante la suspensión.

Política básica

• Normalmente basta con habilitado / valor predeterminado
• Suele tocarse temporalmente al diagnosticar compatibilidad relacionada con la suspensión

8.5 Configuración de la pestaña Power Management

Aparte de la pestaña Advanced, las propiedades del NIC tienen una pestaña Power Management. Esta también es discretamente importante.

Las que se ven con más frecuencia son estas tres.

• Allow the computer to turn off this device to save power
• Allow this device to wake the computer
• Only allow a magic packet to wake the computer

Política básica

• Si hay fallos de reanudación, sospeche primero de Allow the computer to turn off this device...
• Si quiere evitar despertares no deseados, habilite Only allow a magic packet...
• Si no necesita Wake on LAN en absoluto, basta con deshabilitar todos los ajustes de wake

9. Otros ajustes frecuentes pero que rara vez se tocan

9.1 Network Address / Locally Administered Address

Es un ajuste para sobrescribir manualmente la dirección MAC.

Política básica

• Normalmente no se toca
• No es un ajuste de rendimiento
• Se usa solo en entornos de laboratorio o con requisitos especiales

9.2 Adaptive Inter-Frame Spacing

Es un ajuste bastante veterano. En el Ethernet conmutado full-duplex moderno, no es protagonista.

Política básica

• En una LAN moderna y normal, déjelo en el valor predeterminado
• Tóquelo solo en equipos antiguos o entornos especiales cuando el fabricante lo indique

9.3 Header Data Split

Es un tipo de ajuste orientado principalmente a servidores, que ayuda al procesamiento de la CPU separando la cabecera del paquete del payload.

Política básica

• Orientado a servidores / a cargas de trabajo específicas
• En un cliente general, déjelo en el valor predeterminado

9.4 Low Latency Interrupts

Según el fabricante, puede existir un elemento como Low Latency Interrupts.

Política básica

• Úselo solo cuando la medición demuestre una ventaja
• No es un ámbito para habilitarlo por intuición

9.5 Elementos antiguos como TCP Chimney Offload / IPsec Task Offload

En NIC o controladores más antiguos, puede verse este tipo de elementos.

Política básica

• La respuesta correcta hoy es no tocarlos, no usarlos
• No se deje arrastrar por la compatibilidad ni por documentación antigua

10. Pautas generales según el objetivo

Más adelante aparecen varias veces las expresiones «evaluar deshabilitar» y «candidato a deshabilitar». Esto no significa «deshabilítelo», sino conviértalo en objeto de evaluación. En el fondo son los mismos principios generales de 3.3 y 3.4, y en concreto son estos 4 pasos.

1. Guarde la configuración previa al cambio (Export-Csv de 12.1)
2. Deshabilite solo un elemento (3.3)
3. Mida el indicador decidido en 3.4 (throughput, latencia, CPU, estadísticas del NIC, estabilidad de la reanudación)
4. Si no hay efecto, revierta el cambio

Si se omite el paso 4, se van acumulando cambios sin sentido y el siguiente diagnóstico se vuelve más difícil. Lea cada uno de los siguientes elementos como una lista de candidatos sobre los que aplicar estos 4 pasos.

10.1 PC de escritorio o portátil normal

• Speed & Duplex: Auto
• MTU / Jumbo: 1500 / deshabilitado
• Checksum Offload: habilitado
• LSO: habilitado
• RSC: habilitado
• RSS: habilitado
• Interrupt Moderation: valor predeterminado / Adaptive
• Buffers: valor predeterminado
• Flow Control: valor predeterminado
• EEE / Green Ethernet: valor predeterminado
• Selective Suspend: valor predeterminado
• Wake on LAN: solo cuando sea necesario

En resumen, la base es no apartarse del valor predeterminado en principio.

10.2 NAS / copias de seguridad / copias de gran volumen

• Speed & Duplex: Auto
• Jumbo: evaluar si se puede alinear en una ruta dedicada
• Checksum Offload: habilitado
• LSO: habilitado
• RSC: habilitado
• RSS: habilitado
• RSS queues: aumentar un poco si es necesario
• Receive / Transmit Buffers: aumentar un poco si hay drops
• Interrupt Moderation: valor predeterminado / algo más alto
• EEE: evaluar deshabilitar si prioriza la estabilidad

En transferencias grandes, suelen ser efectivas la reducción de la cantidad de paquetes, la reducción de CPU y evitar la falta de colas.

10.3 Cámaras industriales / control de equipos / prioridad en baja latencia

• Speed & Duplex: Auto por norma. Si es necesario, fijarlo acorde al equipo remoto
• Jumbo: evaluar si la cámara, el NIC y el switch quedan alineados
• Checksum Offload: habilitado en principio
• LSO: evaluar deshabilitarlo temporalmente si se sospecha de compatibilidad de envío
• RSC: candidato a deshabilitar si prima la baja latencia o la observación
• Interrupt Moderation: evaluar Low / Off
• Buffers: no aumentarlos en exceso
• Flow Control: es necesario evaluar los efectos secundarios de la pausa
• EEE / Green Ethernet: candidato a deshabilitar
• Selective Suspend / gestión de energía: candidato a deshabilitar

Los ajustes de optimización del throughput no necesariamente son favorables para la baja latencia.

10.4 Host Hyper-V

• VMQ / VMMQ / SR-IOV: evaluar según la configuración
• RSS: importante para el tráfico del lado del host
• RSC: con restricciones según la configuración del vSwitch
• QoS / VLAN: alinear con el diseño del vSwitch
• Flow Control / PFC: considerarlo junto con el diseño de almacenamiento / RDMA

Esto no es tuning de escritorio, sino diseño de infraestructura de virtualización.

10.5 Configuración temporal para diagnóstico de problemas

Para diagnosticar un problema, es efectivo volver por un momento a un escenario simple.

• Speed & Duplex: Auto
• MTU: 1500
• Jumbo: deshabilitado
• EEE: deshabilitado
• LSO: deshabilitado temporalmente
• RSC: deshabilitado temporalmente
• Interrupt Moderation: valor predeterminado o más bajo
• Wake / ahorro de energía: deshabilitado si no es necesario
• Configuración previa al cambio: guardar siempre

En el diagnóstico, simplificar el comportamiento gana a la optimización del rendimiento.

11. Primer punto a revisar según el síntoma

11.1 Debería ser 1 Gbps / 2.5 Gbps, pero se establece en 100 Mbps

El orden general de revisión es más o menos este.

1. Cable
2. Dock / NIC USB / adaptador convertidor
3. Puerto del lado del switch
4. Actualización del controlador
5. EEE / Green Ethernet
6. Volver a poner Speed & Duplex en Auto
7. Si aun así no funciona, probar una fijación acorde con el equipo remoto

La fijación manual de entrada es el último recurso.

11.2 Las transferencias grandes son lentas, pero el ping es normal

Esto es lo que conviene revisar.

• Checksum Offload
• LSO
• RSC
• RSS
• Receive / Transmit Buffers
• Jumbo Frame (si hay una ruta dedicada)
• Estadísticas de drop / error del NIC

Como es un problema del lado del throughput, Jumbo, las colas y los offloads suelen tener efecto.

11.3 La latencia de request/response pequeños es alta, preocupa el jitter

Esto es lo que conviene revisar, en estos 5 puntos.

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• Si los buffers no están sobrecargados

En este ámbito, las optimizaciones que agrupan el procesamiento pueden, al contrario, aumentar la latencia percibida.

11.4 El NIC desaparece tras reanudar desde suspensión / tarda varios segundos en conectar

Lo que conviene revisar, centrado en la alimentación, son estos 5 puntos.

• Selective Suspend
• Configuración relacionada con Device Sleep / Standby
• Allow the computer to turn off this device... en la pestaña Power Management
• Firmware del dock / NIC USB
• Combinación de la configuración de Wake

Los problemas de reanudación suelen deberse más a la gestión de energía que al NIC en sí.

11.5 Se ven muchos errores de checksum en una captura de paquetes

Antes de apresurarse a decir «la línea está rota», revise esto.

• Si Checksum Offload está habilitado
• Si LSO está habilitado
• Si la captura es previa al envío o está sobre el cable
• Si se ve lo mismo al observarlo desde otro host o desde un puerto espejo

Un error de checksum en una captura local es, en la mayoría de los casos, solo la forma en que se ve el offload.

Solo añadimos una aclaración sobre el tercer punto, «si la captura es previa al envío o está sobre el cable». Al capturar en su propio PC, se ve el paquete antes de que el NIC complete el checksum. Si el offload está habilitado, el campo de checksum todavía está vacío o tiene un valor provisional, así que la herramienta de análisis, como es lógico, lo muestra como «inválido». Es bastante habitual que el paquete que realmente circuló por el cable sea correcto.

Las herramientas que suelen usarse para verificarlo son básicamente estas tres.

El registro de pktmon se puede convertir a pcapng, por lo que se puede abrir directamente en Wireshark.

pktmon etl2pcap log.etl --out capture.pcapng

Si «al verlo localmente hay error de checksum, pero al verlo desde el puerto espejo está normal», eso confirma que se trata de la forma en que se ve el offload. Toque la configuración solo después de haber verificado esto.

11.6 Solo las VM de Hyper-V van lentas / la CPU se desequilibra

No basta con revisar solo el RSS típico de escritorio.

• VMQ / VMMQ
• SR-IOV
• vSwitch binding
• VLAN / QoS
• Reparto entre el RSS del lado del host y las colas del lado de la VM

En virtualización, resulta más fácil organizar las ideas si se dibuja quién está procesando cada paquete.

12. Notas prácticas para comprobar y cambiar la configuración con PowerShell

12.1 Primero, guarde el estado actual

La copia de seguridad previa al cambio es importante.

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Select-Object Name, DisplayName, DisplayValue, RegistryKeyword, RegistryValue |
  Export-Csv .\nic-advanced-backup.csv -NoTypeInformation -Encoding UTF8

12.2 Ver el listado

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword -Auto

12.3 Ver RSS / RSC / estadísticas

Get-NetAdapterRss -Name "Ethernet"
Get-NetAdapterRsc -Name "Ethernet"
Get-NetAdapterStatistics -Name "Ethernet"

12.4 Ejemplos de cambio

Como el nombre visible real varía según el NIC, primero revise el listado y después haga el cambio.

# Ejemplo: cambiar Jumbo Packet (el valor varía según el NIC)
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -DisplayName "Jumbo Packet" `
  -DisplayValue "9014 Bytes"

# Ejemplo: configurar el número de colas de recepción de RSS
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 4

12.5 Verificación de conectividad de Jumbo

# Equivalente al MTU estándar de 1500
ping <IP-remota> -f -l 1472

# Equivalente a MTU 9000
ping <IP-remota> -f -l 8972

1472 y 8972 son el payload después de restar la cabecera de IP / ICMP. Estos números del ping no coinciden con el 9014 Bytes que muestra la UI del controlador.

12.6 Notas prácticas

• Algunos ajustes requieren deshabilitar/habilitar el adaptador o reiniciar
• El DisplayName puede estar localizado
• Incluso con el mismo fabricante, el nombre del elemento puede cambiar según la versión del controlador
• Si automatiza con PowerShell, es más seguro enumerar primero los valores del equipo real antes de escribir el script

13. Resumen

La configuración avanzada de NIC en Windows, si solo se mira el nombre de cada elemento, parece que todos son «potentes». Pero en realidad es un mundo en el que la respuesta correcta cambia según cuál se priorice entre throughput, latencia, CPU, energía y compatibilidad.

Los puntos clave de este artículo se resumen así.

• Speed & Duplex, básicamente Auto
• Jumbo, solo cuando queda alineado de extremo a extremo
• Checksum / RSS / LSO / RSC: por norma general, el valor predeterminado es lo más sólido
• Interrupt Moderation es un compromiso entre throughput y latencia
• Buffers, solo lo necesario
• EEE / Selective Suspend / los ajustes de Wake son cuestión de energía y reanudación
• VMQ / SR-IOV son cuestión de Hyper-V
• No toque los elementos de offload antiguos

Y lo más importante son estos tres puntos.

1. Decida qué quiere mejorar
2. Cambie un solo elemento por vez
3. Compare con números el antes y el después

La configuración del NIC no es un interruptor mágico que lo hace todo más rápido. Sin embargo, si el objetivo es el correcto, tiene bastante efecto. Al contrario, si el objetivo está desviado, con bastante frecuencia sale el tiro por la culata.

14. Referencias

A continuación se listan los materiales oficiales / la documentación de fabricantes que se usaron como base para escribir este artículo. Como en Windows y en los controladores de NIC la terminología varía bastante, al final es más seguro verificarla ajustándose al nombre y la versión del controlador de su propio NIC.

• Microsoft Learn: NIC advanced properties
• Microsoft Learn: Network Adapter Performance Tuning in Windows Server
• Microsoft Learn: Hardware Only (HO) features and technologies
• Microsoft Learn: Overview of Single Root I/O Virtualization (SR-IOV)
• Microsoft Learn: Standardized INF Keywords for NDIS QoS
• Microsoft Learn: Standardized INF Keywords for Power Management
• Microsoft Learn: Setting RSS parameters
• Microsoft Learn: Overview of receive segment coalescing
• Microsoft Learn: How to optimize network adapter power management settings
• Microsoft Learn: Deprecated networking features in Windows Server
• Microsoft Learn: Packet Monitor (Pktmon)
• Microsoft Learn: pktmon etl2pcap
• Microsoft Learn: UDP Segmentation Offload (USO)
• Microsoft Learn: UDP Receive Segment Coalescing Offload (URO)
• Intel Support: Advanced Settings for Intel Ethernet Adapters
• Intel Support: es más seguro verificar la fijación de velocidad, Jumbo, Interrupt Moderation, EEE, WoL, etc., a partir del artículo de soporte correspondiente al modelo de NIC

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Se debe deshabilitar Large Send Offload (LSO)?

Por lo general es un ajuste que conviene dejar habilitado. LSO es el mecanismo por el cual el NIC divide en tramas más pequeñas los datos de envío TCP de gran tamaño, y ayuda a mejorar el throughput y a reducir el uso de CPU en comunicaciones con mucho envío de datos. Deshabilitarlo sin criterio tiende a hacer que se consuma CPU de forma innecesaria. Vale la pena considerar deshabilitarlo cuando se sospecha de un problema de compatibilidad con una aplicación o un controlador concreto y se quiere apagarlo temporalmente para comparar la diferencia, o cuando se quiere evaluar la compatibilidad de envío en escenarios como cámaras industriales o control de equipos. Incluso si se deshabilita con fines de diagnóstico, la norma es volver al valor predeterminado en cuanto se determina que la causa es otra.

¿Qué es Receive Segment Coalescing (RSC)? ¿Conviene deshabilitarlo?

RSC es un ajuste por el cual el NIC agrupa en el lado de recepción varios segmentos TCP, y también se conoce como Large Receive Offload. Como ayuda a mejorar el throughput de recepción y a reducir el uso de CPU, la política básica es mantenerlo habilitado cuando la prioridad es la recepción. Por otro lado, puede resultar desfavorable en escenarios de baja latencia o de observación a nivel de paquete, y la interpretación de las capturas de paquetes y de las mediciones de tiempo cambia ligeramente. En escenarios donde se quiere reducir la latencia de request/response pequeños, o en entornos donde priman la baja latencia y la observación, es un candidato a evaluar para deshabilitarlo. Puede consultar el estado actual con Get-NetAdapterRsc.

El enlace debería ser de 1 Gbps, pero se establece a 100 Mbps. ¿Qué se debe revisar?

Fijar manualmente Speed & Duplex de entrada es el último recurso. El orden de revisión es, en general: primero el cable, después el dock / NIC USB / adaptador convertidor, el puerto del lado del switch, la actualización del controlador, descartar EEE / Green Ethernet, volver a poner Speed & Duplex en Auto y, si aun así no funciona, probar una fijación acorde con el equipo remoto. Esto se debe a que el downshift a 100 Mbps y los cortes de enlace suelen tener su causa en la capa física o en el equipo remoto más que en la configuración del NIC. Un estado en el que un lado está fijado y el otro en Auto provoca duplex mismatch, y esto causa caída de velocidad, retransmisiones y latencias anómalas.

En definitiva, ¿qué ajustes de la configuración avanzada de NIC en Windows conviene habilitar?

En un PC de escritorio o portátil normal, la norma básica es no apartarse de los valores predeterminados. Speed & Duplex en Auto; Checksum Offload / LSO / RSC / RSS habilitados o en su valor predeterminado por regla general; y Jumbo Packet solo cuando el NIC, el equipo remoto y el switch intermedio quedan alineados de extremo a extremo. EEE y Selective Suspend son ajustes de ahorro de energía, no ajustes para ganar velocidad. Al hacer cambios, la regla de oro es decidir primero qué se quiere mejorar (throughput, latencia, CPU, consumo de energía), cambiar un solo elemento por vez y comparar con números el antes y el después.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.