Cómo usar NTTTCP en Windows: pruebas, comandos y ajustes pro

Si necesitas medir el rendimiento real de tu red en Windows (y también en Linux) sin que el almacenamiento o la CPU te condicionen, NTTTCP es una de las utilidades más fiables para poner a prueba el ancho de banda y la latencia práctica. Esta herramienta de Microsoft centra la carga en la capa de red y te ayuda a detectar cuellos de botella, problemas de configuración y límites físicos del enlace.

En este artículo reunimos y reorganizamos en una guía única todo lo esencial para usar NTTTCP: requisitos, instalación en Windows y Linux, comandos clave, parámetros de prueba recomendados (como fijar una duración común con -t), ejecución en máquinas virtuales y en Amazon EC2, afinado de la ventana TCP, lectura de resultados (MB/s, Mbps, ciclos/byte, DPC, interrupciones) y cómo interpretar retransmisiones y errores. También verás cuándo tiene sentido usar iperf u otras herramientas como ctsTraffic.

Qué es NTTTCP y por qué usarlo

NTTTCP (NT Test TCP) es una utilidad gratuita de Microsoft diseñada para medir el rendimiento de red, tanto en equipos físicos como en máquinas virtuales, con un enfoque directo sobre la pila TCP/UDP. Su ventaja es que minimiza la influencia de otros subsistemas (discos, servicios de fondo, etc.) para que el test refleje el comportamiento real del enlace.

Está disponible para Windows, y existe una implementación compatible para Linux (ntttcp-for-linux), de modo que puedes realizar pruebas homogéneas en distintos sistemas operativos. Es especialmente útil en entornos de nube como Azure o AWS, donde la configuración de instancias, colas de red y drivers impacta de forma notable.

NTTTCP permite controlar el número de hilos, el mapeo de CPU, los puertos y varios temporizadores, además de habilitar modos específicos para pruebas mixtas entre Windows y Linux. Con ello puedes simular cargas realistas, saturar múltiples colas de NIC y observar el impacto en interrupciones, DPC, ciclos/byte y uso de CPU.

Requisitos y ejemplo de entorno

Antes de nada, asegúrate de disponer de dos equipos o VMs con conectividad entre sí (rutas, grupos de seguridad/red, firewall) y privilegios para instalar/ejecutar herramientas. Conviene tener permisos de administrador en Windows y sudo en Linux.

Ejemplo de parámetros usados a lo largo del texto (puedes adaptarlos):

Parámetro	Valor
IP del receptor	10.0.0.5
Núcleos de CPU por VM	2

En redes de 1 GbE, una transferencia sostenida alrededor de 112 MB/s suele indicar que estás cerca del máximo teórico, siempre que la pila TCP esté bien ajustada y no haya pérdidas. En enlaces de 10 GbE o superiores, será imprescindible revisar la ventana TCP y, en algunos casos, activar tramas jumbo de forma consistente.

Instalación y preparación en Windows y Linux

Windows: descarga la versión más reciente de NTTTCP desde el repositorio oficial de Microsoft (GitHub), descomprime el paquete y abre una consola con privilegios de administrador. A continuación, cambia al directorio que corresponda con la arquitectura de tu sistema (por ejemplo, x64) para ejecutar la utilidad.

Linux: para usar ntttcp-for-linux, instala primero las dependencias y compílalo. En Ubuntu bastará con build-essential y git; en SUSE, con git-core, gcc y make. Después, clona y compila el proyecto.

Comandos de preparación en Ubuntu (ajústalos si tu distro difiere):

Ejecuta en la VM Linux y verifica que no hay errores:
sudo apt-get update && sudo apt-get -y install build-essential git

Comandos de preparación en SUSE (instala los paquetes y resuelve dependencias si aparecen):
sudo zypper in -y git-core gcc make

Clonado y compilación de ntttcp-for-linux (desde cualquier distro compatible):
git clone https://github.com/Microsoft/ntttcp-for-linux && cd ntttcp-for-linux/src && sudo make && sudo make install

Cómo ejecutar pruebas de rendimiento con NTTTCP en Windows

La recomendación habitual es fijar una duración de 300 segundos (-t 300) en emisor y receptor para estabilizar el caudal y observar métricas de CPU e interrupciones durante un periodo significativo. Ambos lados deben usar el mismo valor de -t.

En el receptor (Windows), ejecuta sustituyendo el número de núcleos y la IP de destino por los tuyos:
ntttcp -r -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Ejemplo receptor con 2 núcleos (4 hilos) usando la IP del ejemplo:
ntttcp -r -m 4,*,10.0.0.5 -t 300

En el emisor (Windows), el comando es análogo pero cambiando -r por -s para indicar que envía:
ntttcp -s -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Ejemplo emisor con 4 hilos apuntando al receptor 10.0.0.5:
ntttcp -s -m 4,*,10.0.0.5 -t 300

Qué observar en la salida: throughput por hilo, MB/s totales, tamaño medio de trama, buffers/s, ciclos/byte, DPC, interrupciones, paquetes enviados/recibidos, retransmisiones, errores y %CPU. Estos campos ayudan a ver si el ancho de banda está limitado por la pila TCP, por la NIC o por la CPU.

Cómo ejecutar NTTTCP en Linux

En Linux, la sintaxis es prácticamente calcada. Recuerda que si no indicas -t, la duración por defecto suele ser de 60 segundos, lo que puede no ser suficiente para una medición estable.

Receptor (Linux) con 4 hilos y 5 minutos de duración:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Emisor (Linux) apuntando al mismo receptor e igual duración:
ntttcp -s -m 4,*,10.0.0.5 -t 300

La salida típica en Linux resume conexiones creadas, duración, bytes totales, throughput (Mbps), retransmisiones (retrans segs) y uso de CPU. Además, verás indicadores como ciclos/byte o el porcentaje de CPU ocupada, útiles para entender la eficiencia de la pila.

Pruebas mixtas entre Windows y Linux

Para testear entre un Windows y un Linux, activa el modo sin sincronización para evitar desajustes en el handshaking interno: en Windows añade -ns y en Linux añade -N. Con ello, la coordinación entre extremos se simplifica y evita bloqueos por diferencias de implementación.

Ajustes de red relevantes: tamaño de ventana TCP/IP

En enlaces de 1 GbE y baja latencia, la ventana TCP por defecto (~64 KB con SO_RCVBUF en NTttcp) suele ofrecer buen rendimiento. Esto evita tener que modificar parámetros de la pila para casos sencillos de LAN.

En redes de alta latencia o en 10 GbE y superiores, la ventana por defecto puede quedarse corta, reduciendo el caudal efectivo. Aquí conviene ajustar el tamaño de la ventana TCP para soportar un producto ancho de banda x retardo mayor.

NTTTCP permite fijar estáticamente la ventana con -rb, lo que deshabilita el autotuning de la pila. Empléalo solo si comprendes bien las implicaciones, porque forzar una ventana grande en escenarios inadecuados puede degradar el rendimiento.

Como pauta general, empieza con la configuración por defecto y escala solo si tu caso lo exige (latencia alta, WAN, múltiples saltos). Complementa estas pruebas con guías de afinado de red del sistema operativo para ajustes persistentes.

NTTTCP en instancias Amazon EC2 (Windows)

Si operas en AWS, puedes usar NTTTCP para elegir tipos de instancia, tamaños y configuraciones óptimas. Las pruebas te ayudarán a contrastar el rendimiento real frente a lo publicado por AWS para cada familia de EC2.

Pasos previos recomendados en EC2 (Windows):

• Arranca dos instancias Windows para las pruebas de red.
• Verifica que soportan Enhanced Networking (drivers actualizados y tipo de instancia compatible).
• Ajusta la MTU si no están en el mismo Placement Group o no usan jumbo frames, manteniendo coherencia extremo a extremo.
• Comprueba conectividad (RDP, ping si procede, rutas y seguridad).

Instalación en ambas instancias: descarga la última versión de NTttcp de Microsoft, descomprime en una carpeta y abre CMD como Administrador. Entra en el directorio que corresponda con la arquitectura de tu instancia antes de ejecutar.

Puertos y seguridad: por defecto, NTTTCP utiliza el puerto 5001 para TCP y UDP, aunque puedes cambiarlo con -p. Asegura que los Security Groups y el Firewall de Windows permiten el tráfico necesario y las conexiones a ntttcp.exe (entrantes y salientes).

Prueba de rendimiento TCP en EC2 (receptor): inicializa el listener a partir del puerto elegido. Ejemplo con dos hilos en puertos 80–81, asignados a CPU 0 y 1:
ntttcp -r -p 80 -a 6 -t 60 -cd 5 -wu 5 -v -xml c:\bench.xml -m 1,0,192.168.1.4 1,1,192.168.1.4

Significado de los parámetros anteriores (receptor):

• -r: modo recepción.
• -p 80: puerto base del primer hilo (se incrementa por hilo adicional).
• -a 6: E/S asíncrona con 6 buffers de recepción superpuestos por hilo.
• -t 60: duración de la prueba en segundos.
• -cd 5: cooldown de 5 s para estabilizar el final de prueba.
• -wu 5: warmup de 5 s para estabilizar el inicio.
• -v: salida detallada.
• -xml c:\bench.xml: guarda resultados en XML en la ruta indicada (por defecto xml.txt).
• -m: mapeo por sesión (hilos, ID de CPU, IP del receptor), separando sesiones por espacios.

Prueba de rendimiento TCP en EC2 (emisor): usa los mismos parámetros, cambiando a modo envío y apuntando a la IP del receptor en ambos comandos:
ntttcp -s -p 80 -a -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

Significado de los parámetros específicos (emisor):

• -s: modo envío.
• -p 80: puerto base por hilo (incrementa por hilo).
• -a: buffers de envío superpuestos por hilo (por defecto 2, especifícalo si quieres otro valor).
• -t, -cd, -wu: duración, cooldown y warmup, igual que en el receptor.
• -m: mapeo de hilos, CPU e IP del receptor, idéntico al lado servidor.

Salida y métricas: en el receptor puedes guardar un XML con desglose por hilo (tiempo real, KB/s y MB/s, Mbps, bytes por completado, ancho de banda total, buffers/s, interrupciones por segundo, DPC/s, ciclos/byte, paquetes enviados/recibidos, retransmisiones, errores y %CPU). En una prueba de muestra con 2 hilos, el agregado puede rondar valores del orden de varios Gbps (p.ej., ~9 Gbps) en instancias adecuadas y red bien ajustada.

Prueba de rendimiento UDP en EC2: para validar el plano de datos sin control de congestión de TCP, utiliza el switch -u. Receptor con dos hilos en puertos 80–81:
ntttcp -r -u -p 80 -t 60 -cd 5 -wu 5 -v -xml c:\bench.xml -m 1,0,192.168.1.4 1,1,192.168.1.4

Emisor UDP equivalente, respetando IP y puertos:
ntttcp -s -u -p 80 -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

En UDP observarás MB/s, Mbps, tamaño medio por completado y buffers/s, junto con contadores de interrupciones y DPC. A diferencia de TCP, no hay garantías de entrega, así que errores y pérdidas son más visibles si fuerzas al límite la red.

Interpretar resultados: throughput, retransmisiones y errores

Throughput (MB/s y Mbps): es el caudal efectivo. En 1 GbE, lo esperable es ~940 Mbps (unos 112 MB/s) si todo está bien. En 10 GbE, niveles próximos a 9–9.5 Gbps son razonables sin jumbo frames y mejores con configuración óptima.

Buffers/s, tamaño medio de trama y ciclos/byte: te cuentan cuánta carga mueve cada hilo y la eficiencia del stack. Ciclos/byte altos sugieren que la CPU se está esforzando demasiado por cada byte transferido.

DPC/s e interrupciones por segundo: si se disparan, piensa en optimizar RSS/RSC/RDMA (si aplica), drivers y distribución de hilos por CPU. Un reparto deficiente puede crear hot-spots en un solo núcleo.

Retransmisiones: ver algunas retransmisiones puede ser normal bajo carga, pero cifras elevadas sostenidas indican pérdidas o congestión. Con 1 GbE limpio, las retrans deberían ser bajas; si ves miles en pocos minutos, revisa cableado, calidad de enlaces, colisiones (full-duplex mal negociado), offloads (intenta desactivar LSO/TSO para pruebas), colas de NIC y presión de buffers.

Errores: lo ideal es cero. Si aparecen, busca CRC en switches/NIC, MTU inconsistente, drivers antiguos o reglas de firewall/IDS que inspeccionan en exceso. Asegura coherencia de jumbo frames si los usas y que ambos extremos admiten el mismo MTU.

Casos prácticos: si en una LAN de 1 GbE obtienes ~112 MB/s pero ves ~3.000 retrans y ~400 errores en 5 minutos, hay indicios de pérdida intermitente. Prueba a cambiar cable/puerto, actualizar drivers, revisar flow control, desactivar temporales offloads, y repetir. Si las retrans bajan drásticamente, has dado con el foco.

iperf vs NTTTCP y otras herramientas útiles

iperf es excelente para una comprobación rápida y multiplataforma, y te ayuda a demostrar si la red puede sostener 1G/10G entre dos puntos concretos. Es muy útil para descartar la red cuando el problema está en la aplicación o el almacenamiento.

NTTTCP ofrece más control fino en Windows (mapeo de hilos y CPU, modos asíncronos, XML detallado, métricas de DPC/interrupts) y una implementación para Linux que facilita pruebas homogéneas. En entornos Microsoft/Azure, suele ser la referencia.

ctsTraffic (Client to Server Traffic) es otra herramienta de Microsoft para generar y verificar tráfico. Puede complementar NTTTCP si quieres perfilar patrones de cliente-servidor más variados.

Metodología para ‘apagar incendios’ entre equipos: ejecuta pruebas desde los hosts afectados y por el mismo camino de red. Repite en distintos horarios, añade pruebas UDP controladas y recopila capturas en NIC/switch. Solo con throughput alto en iperf/NTTTCP, baja retrans y errores nulos podrás defender con datos que la red no es el cuello de botella.

Siguientes pasos e información relacionada

Verifica la MTU y la consistencia extremo a extremo (especialmente si combinas tramas jumbo). En AWS, evalúa Placement Groups y Enhanced Networking. En Azure, alinea el tamaño de VM con tus objetivos de caudal.

Experimenta con el número de hilos (-m) y la fijación por CPU para aprovechar RSS y múltiples colas de la NIC. Ajusta -t a 300 s para pruebas estables y usa -xml para conservar resultados con los que comparar.

Si debes mezclar Windows y Linux, recuerda -ns/-N. Y si la latencia es significativa, evalúa aumentar la ventana TCP con -rb únicamente para validar hipótesis, manteniendo precaución con el autotuning deshabilitado.

Una guía práctica como esta, que combina comandos, interpretación y ajustes, te permitirá medir, entender y mejorar tu red sin ruido de otros subsistemas, dejando claro si el límite está en la infraestructura, en la configuración o en el propio diseño de la aplicación.