iperf3 en multi-thread para exprimir 10GbE: guía completa

En redes de 10GbE cada vez más comunes en equipos domésticos y profesionales, el cuello de botella suele trasladarse de la tarjeta a la CPU. Por eso, ajustar iperf3 para explotar varios hilos puede marcar la diferencia entre quedarse en 6–8 Gbps o rozar la saturación del enlace. En esta guía vas a ver, con ejemplos reales, cómo aprovechar el modo multihilo, qué versiones necesitas y qué trampas de hardware evitar para no perder rendimiento.

Más allá de ejecutar un comando, el éxito depende de la versión de iperf3, la configuración del sistema, los drivers de la NIC y hasta de la anchura del enlace PCIe. Verás casos prácticos (desde un mini PC con Intel N100 hasta un servidor con TrueNAS y Proxmox), parámetros clave de iperf3, buenas prácticas para interpretar resultados y una checklist de diagnóstico cuando el contador se queda clavado.

Qué es iperf3 y por qué importa en 10GbE

iperf3 es una herramienta de código abierto para medir el ancho de banda entre dos equipos mediante TCP, UDP o SCTP. Es multiplataforma (Windows, Linux, macOS, BSD, entre otros) y su código se reescribió desde cero respecto a iperf2 para simplificar, añadir salida JSON y convertirse en una base modular más fácil de integrar en otros programas.

Frente a otras utilidades, permite ajustar tamaño de ventana TCP, definir cantidades de datos, seleccionar protocolo y generar múltiples conexiones simultáneas. En UDP mide jitter y pérdidas, soporta multicast y puede fijar el caudal objetivo; en TCP ofrece opciones como zero-copy, control de congestión y salida detallada por intervalos.

En enlaces de 10 Gbps o superiores, una sola conexión TCP puede no bastar para saturar el enlace; distribuir la carga en varios flujos y, desde iperf3 3.16, aprovechar multithreading de forma más sencilla ayuda a llenar el tubo cuando la CPU o la pila de red limitan.

Versiones: requisito mínimo y compatibilidades

Antes de nada, comprueba la versión en ambos extremos con iperf3 -v. Desde la 3.16 iperf3 simplifica el uso multihilo, reduciendo la necesidad de trucos y comandos adicionales que eran habituales en entornos de 40 Gbps en adelante. Si tu distro va por detrás (caso típico en hipervisores o appliances), compilar la última versión suele ser la vía rápida; y revisa los tipos de red en hyper‑V, VirtualBox y VMware de tu entorno.

Un ejemplo real: en un entorno con OpenWrt/QWRT y Proxmox VE 8.3, OpenWrt ya traía una versión reciente, pero Proxmox estaba desfasado. Se resolvió compilando iperf 3.18 desde fuente en el host Proxmox, y a partir de ahí se habilitó el multihilo con normalidad.

Preparación del entorno 10GbE: CPU, NIC, drivers y PCIe

Para alcanzar picos cercanos a 9.8–9.9 Gbps, no basta con cables Cat6A y un switch 10G. Hay que mirar más abajo: versión del driver, RSS (Receive Side Scaling), interrupt coalescing, offloads (TSO/GSO/GRO/LRO) y, sobre todo, el enlace PCIe de la tarjeta.

En Windows 10/11, especialmente con NICs 10G como la ASUS XG-C100C, actualiza el driver, habilita RSS y revisa si SMB Multichannel está activo y audita la conexión de red en Windows. En transferencias de ficheros con NAS (ej. QNAP con QuTS Hero), la velocidad dependerá también del rendimiento del almacenamiento y de la CPU del NAS; es normal ver ~6–8 Gbps si el RAID o el ZFS no acompañan, mientras que iperf3 (memoria a memoria) sí puede acercarse a 10GbE.

En Linux y BSD, verifica que la tarjeta negocia el ancho PCIe correcto. Un caso típico: un cliente se quedaba en ~3.5 Gbps pese a tener 10GbE porque el slot funcionaba degradado a x1 a 5 GT/s. El comando lspci -vv mostró “LnkSta: Speed 5GT/s, Width x1 (degraded)”. Tras ajustar la BIOS para forzar el puerto a x16, la velocidad saltó a ~9.84 Gbps.

Modo multihilo en iperf3: comandos imprescindibles

El patrón básico de pruebas es sencillo: lanza el servidor con iperf3 -s en un extremo y ejecuta el cliente desde el otro. A partir de aquí, añade paralelismo:

• Múltiples flujos TCP: iperf3 -c IP_SERVIDOR -P 4 genera 4 conexiones paralelas. Ajusta -P a tu CPU/NIC; en 10GbE, 4–8 suele bastar.
• Bidireccional simultáneo: iperf3 -c IP_SERVIDOR -P 4 -d mide subida y bajada a la vez, útil para validar full duplex.
• Sentido inverso (tráfico del servidor al cliente): -R.
• Duración: -t 60 para pruebas de 60 s; descarta arranques con -O 3 para evitar el slow start de TCP.
• Zero-copy: -Z reduce la carga de CPU en Linux.
• Afinidad de CPU: -A fija la afinidad (útil para distribuir hilos en núcleos distintos).
• Binding a interfaz: -B 10.0.0.2 elige explícitamente la IP/IF de salida (consulta cómo listar las interfaces de red en CMD).

Si trabajas con UDP, controla el caudal con -b y revisa pérdidas/jitter; aunque para saturar 10GbE y medir la pila del sistema, TCP suele ser el punto de partida.

Caso práctico 1: mini PC Intel N100 con dos 10GbE

Escenario: dos iKOOCORE R2 Max (uno fanless con OpenWrt/QWRT como servidor y otro con Proxmox VE como cliente), ambos con dual 10GbE y CPU Intel N100 de 4 núcleos. En la primera medición se observó ~9.41 Gbps de subida, pero la descarga se quedaba en ~8.6 Gbps, y el test bidireccional iba peor.

HTOP mostró la pista: un solo núcleo al 100% mientras el resto estaban ociosos. Aunque el uso total de CPU rondaba el 30%, una única hebra saturada limitaba el throughput efectivo. Para solucionarlo se inició el servidor como siempre (iperf3 -s) y en el cliente se añadió -P 4 para abrir 4 flujos.

La salida, con intervalos de 10 s y cuatro hilos, es más verbosa, pero lo importante es que se consiguió la cifra objetivo: ~9.41 Gbps. En la prueba full duplex con -d, los sumatorios y promediaron ~9.40 Gbps en ambos sentidos durante un minuto, confirmando que la CPU ya repartía la carga entre varios hilos y la NIC saturaba el enlace.

Como nota práctica: si la versión del cliente es antigua (como ocurría con Proxmox), compilar iperf 3.18 resolvió el salto de prestaciones y la compatibilidad de opciones recientes en el lado que más lo necesitaba.

Caso práctico 2: TrueNAS + Proxmox y el cuello de botella PCIe

Configuración: servidor con TrueNAS-13.0-U6 (FreeBSD 13.1) sobre placas Supermicro x8/x9, CPU dual Intel Westmere E5645 y NIC Chelsio T420-CR; cliente con Proxmox VE 8.1.3 (Debian 12, kernel 6.5.11), CPU dual E5-2420 v2 y NIC Chelsio T440-CR. Cableado directo por DAC twinax entre hosts.

El primer test se clavó en ~3.55 Gbps de media, con cero retransmisiones y ventana congestionada estable. La CPU ni se despeinaba: ~13–20% de uso por iperf3. La pista decisiva llegó al mirar el estado del enlace PCIe: “LnkSta: Speed 5GT/s, Width x1 (degraded)”. Es decir, la NIC 10G estaba atada a un carril PCIe x1 a 5 GT/s, limitando el caudal.

Tras bucear en la BIOS se encontró una opción crítica en Supermicro X9DBU-3F: Advanced → Chipset Configuration → North Bridge → Integrated IO Configuration → IIO 1 IOU3 – PCIe Port. Cambiando de “Auto” a “x16”, el enlace recuperó anchura y velocidad correctas. Resultado: iperf3 marcó ~9.84 Gbps de forma sostenida, con cero retransmisiones y Cwnd estable.

Además, abriendo dos clientes contra dos puertos distintos (-p 5000 y -p 5001) se alcanzaron ~19.58 Gbps agregados. En ese escenario de doble puerto, dos hilos del Westmere iban al 70–80% y el Ivy Bridge al 30–40%, coherente con la carga multiproceso al empujar tráfico por dos interfaces 10G a la vez.

Interpretar resultados: qué mirar y cómo ajustar

En la salida de iperf3, fíjate en la tasa media final y en las líneas de intervalo (por defecto, 1 s; en algunos ejemplos se usa 10 s). Si multiplicas los MBytes transferidos por 8 y divides entre el tiempo del intervalo, el número debe cuadrar con los Gbits/s reportados.

Si ves un único hilo saturado y el total no sube, aumenta -P gradualmente (4, 6, 8) hasta que el throughput deje de crecer. Si sube algo pero no llega a 9.8–9.9 Gbps, revisa offloads y RSS. Cuando hay pérdidas o retransmisiones en TCP, evalúa -w (ventana), -O (omitir arranque) y la calidad del enlace físico.

En bidireccional (-d), mira los sumatorios y del minuto para validar que ambas direcciones rozan el máximo teórico. Diferencias grandes entre subida y bajada suelen apuntar a afinidad, IRQs o RSS mal distribuidos.

Cuando no es la CPU: diagnóstico de “6 Gbps” crónicos

Si te quedas en ~6–7 Gbps (muy típico en setups nuevos), descarta estos puntos uno por uno:

• Versión antigua: clientes 3.7 con servidores 3.16 funcionan, pero actualiza ambos para beneficiarte de mejoras de multihilo y correcciones.
• PCIe degradado: verifica ancho y velocidad con lspci -vv (Linux) o herramientas del fabricante; un x1 a 5 GT/s estrangula la NIC 10G.
• RSS desactivado: sin reparto de interrupciones, un solo core queda al 100%. En Windows habilítalo en el driver; en Linux revisa ethtool -l y RPS/RFS.
• Offloads y coalescing: TSO/GSO/GRO/LRO y la coalescencia de interrupciones reducen la carga de CPU; ajusta con ethtool.
• MTU/Jumbo frames: no siempre sube el throughput, pero en CPU débiles ayuda. Actívalo en ambos extremos y en el switch si lo soporta.
• Almacenamiento: en pruebas con NAS, el cuello puede ser el RAID/ZFS; usa iperf3 para aislar red (memoria a memoria) y no el disco.
• SMB y multicanal: en Windows, SMB Multichannel acelera copias; si no está activo, los ficheros irán más lentos aunque iperf3 marque 9–10 Gbps.

También conviene ajustar buffers del sistema en Linux cuando se buscan picos sostenidos: sysctl net.core.rmem_max y net.core.wmem_max altos evitan cuellos de socket; no son obligatorios para 10GbE en LAN de baja latencia, pero ayudan en escenarios exigentes.

Instalación rápida en Windows, Linux y macOS

En Windows descarga los binarios de confianza, descomprime y ejecuta desde CMD o PowerShell; si Windows no detecta la tarjeta de red, consulta la guía de soluciones. Abre una consola, ve a la carpeta y ejecuta iperf3.exe -s o iperf3.exe -c IP. Asegúrate de permitir el puerto 5201/TCP en el cortafuegos si haces pruebas entre subredes.

En Linux/macOS, instalar suele ser un comando: en Debian/Ubuntu sudo apt-get install iperf3, en RHEL/CentOS sudo yum install iperf3, en macOS con Homebrew brew install iperf3. Si tu sistema va atrasado, compilar desde fuente te da la última versión.

Parámetros útiles de iperf3 (cliente y servidor)

Para controlar la sesión en detalle, estos flags te ahorran tiempo:

• Generales: -p puerto, --cport puerto cliente (>=3.1), -f formato (k/K/m/M/g/G), -i intervalo, -F archivo, -B bind, -V verbose, -J JSON, --logfile (>=3.1), -h ayuda, -v versión.
• Servidor: -s servidor, -D demonio, -I PID file.
• Cliente: -c IP, --sctp SCTP, -u UDP, -b ancho de banda, -t tiempo, -n bytes, -k paquetes, -l longitud buffer, -P hilos, -R reverse, -w ventana TCP, -M MSS, -N TCP no-delay, -4/-6 IPv4/IPv6, -S TOS, -L etiqueta IPv6, -Z zero-copy, -O omitir arranque, -T título, -C algoritmo de congestión.

Recuerda que -P aplica por flujo. Si fijas -b en UDP o el sistema impone límites de socket, cada hilo puede toparse con su propio techo; experimenta con menos hilos pero mejor ajustados.

Impacto y limitaciones: lo que iperf3 mide (y lo que no)

iperf3 es excelente para estresar la red, pero puede inundar tu LAN si lo ejecutas en producción. Evita pruebas largas en horas pico, y coordina con otros equipos si compartes enlaces troncales. Su patrón de tráfico no siempre replica cargas reales de aplicaciones.

Entre sus pegas, no trae interfaz gráfica de serie, requiere toquetear parámetros y no guarda históricos por sí mismo. Aunque soporta muchos protocolos, hay escenarios (p. ej., ciertas funcionalidades IPv6 o multiplexión específica) donde otras herramientas pueden encajar mejor.

Alternativas cuando necesitas otra cosa

Si iperf3 no encaja en tu caso, estas opciones te pueden salvar:

• iperf2: legado pero útil para compatibilidades antiguas; existe GUI (jperf) clásica.
• netperf: muy potente para TCP/UDP y latencia, más técnico de manejar.
• nuttcp: ligera para medir ancho de banda/pérdidas sin demasiada complicación.
• bwping/bwping6: ICMP para estimar ancho de banda cuando no puedes abrir TCP/UDP (menos preciso).
• Speedtest CLI / Fast.com CLI: para Internet pública; no sustituyen a iperf3 en LAN.

Si tu objetivo es exprimir 10GbE, empieza por iperf3 multihilo: verifica versión ≥3.16, habilita 4–8 hilos, comprueba RSS y el enlace PCIe, y revisa drivers/offloads. Con estos mínimos, equipos modestos como un Intel N100 han saturado 10GbE (9.40–9.85 Gbps), y configuraciones más veteranas han pasado de 3.5 a 9.8 Gbps tras corregir un simple x1 en PCIe. La clave está en repartir el trabajo entre núcleos, evitar cuellos ocultos y leer las métricas adecuadas para saber cuándo tocar cada parámetro.