Cómo medir si tu internet anda mal: latencia, jitter y MTR

“Anda lento” es un síntoma; no es un diagnóstico. Antes de pelearse con el proveedor, conviene medir bien y mostrar números concretos. Con tres herramientas gratuitas alcanza para tener una foto seria del estado del servicio.

Este post te explica qué medir, con qué herramientas, y cómo leer los resultados.

Las cuatro métricas que importan

Wikipedia, en su artículo de Network performance, define las métricas estándar (fuente):

1. Bandwidth / Throughput — velocidad real de transferencia.
2. Latencia — demora ida y vuelta hasta un destino, en milisegundos.
3. Jitter — variación de la latencia.
4. Packet loss — porcentaje de paquetes perdidos.

Speedtest popular mide básicamente el primero. Para diagnóstico real necesitás los cuatro.

Herramienta 1 — Speedtest (Ookla y similares)

Sirve para una primera aproximación. Mide:

• Velocidad de bajada (download)
• Velocidad de subida (upload)
• Ping al servidor más cercano

Lo que hace bien: te da el throughput aproximado en condiciones ideales (servidor cercano, sin otros dispositivos consumiendo ancho).

Lo que hace mal: no mide jitter sostenido, no muestra packet loss, y los servidores Speedtest están dentro de la red de los carriers, lo que infla el resultado vs. tráfico real a internet (un Netflix, un Google Workspace).

Cómo usarlo serio: corré Speedtest 5 veces seguidas en distintos momentos del día (mañana, mediodía, prime time 21-23 hs). Anotá el promedio. Si tu plan es 300/300 y el promedio en prime time es 90/40, tenés un problema.

Herramienta 2 — Ping

Comando de toda la vida, disponible en Windows, macOS y Linux. Wikipedia lo describe como “una utilidad administrativa de red usada para probar la accesibilidad de un host en una red IP” (fuente).

# Linux / macOS / Windows
ping -c 100 8.8.8.8

(En Windows: ping -n 100 8.8.8.8)

Lo que mirás al final:

• min / avg / max de latencia
• packet loss (idealmente 0%)
• mdev / stddev — la desviación es jitter aproximado

Valores razonables (orientativos, no son norma):

Métrica	Bueno	Aceptable	Malo
Latencia a 8.8.8.8 desde AR	< 30 ms	30–80 ms	> 80 ms
Packet loss	0%	< 0.5%	> 1%
Jitter (mdev)	< 5 ms	5–20 ms	> 20 ms

(Estas referencias provienen de la operatoria habitual del sector, no de norma oficial.)

Herramienta 3 — MTR (My Traceroute)

La más útil de todas para diagnóstico. Wikipedia lo define como “un programa de diagnóstico de red que combina las funciones de los programas tradicionales traceroute y ping en una herramienta única” (fuente).

Muestra cada salto entre vos y el destino, con latencia y pérdida de paquetes en cada uno. Esa diferencia es clave: si el packet loss aparece recién en el salto 7 (ya en backbone), el problema no es tuyo. Si aparece en el salto 1 o 2 (CPE o última milla del proveedor), es local.

Instalación

• Windows: WinMTR (código abierto)
• Linux: apt install mtr o yum install mtr
• macOS: brew install mtr

Uso

mtr -rwbzc 200 8.8.8.8

Flags:

• -r reporte (no interactivo)
• -w wide (mostrar nombres completos)
• -b mostrar IP además de nombre
• -z mostrar AS number
• -c 200 200 ciclos

Cómo leer la salida

HOST: gateway-empresa            Loss%   Snt   Last   Avg  Best  Wrst StDev
1. AS???    192.168.1.1           0.0%   200    1.2   1.3   1.0   2.1   0.3
2. AS27747  10.x.x.x              0.0%   200    8.5   9.1   7.2  18.4   1.8
3. AS27747  cust-router.isp.ar    0.5%   200   12.0  13.5  10.5  45.0   4.2
4. AS27747  edge.ba.isp.ar        0.5%   200   15.5  16.0  14.0  38.0   3.1
5. AS15169  72.14.x.x             8.5%   200   28.3  35.0  26.0 102.0  12.5
6. AS15169  72.14.x.x             0.5%   200   30.1  31.0  28.5  55.0   3.8
7. AS15169  dns.google            0.0%   200   31.0  31.5  29.8  48.0   2.1

Lo que se lee de este ejemplo ficticio:

• Hops 1–4 (red propia + ISP) con loss 0–0.5%: razonable.
• Hop 5 muestra 8.5% de loss — pero los hops siguientes tienen 0%. Esto es muy importante: packet loss en un salto intermedio que no se propaga suele ser un router que prioriza ICMP bajo (cosmético, no afecta tráfico real).
• Si el loss del hop 5 se mantuviera en hops 6 y 7, ahí sí hay problema real.

Esa es la trampa principal de leer MTR: lo que importa es si la pérdida se sostiene hasta el destino.

Herramienta 4 — iperf3

Cuando querés medir capacidad real entre dos puntos (no contra Speedtest), iperf3 es la herramienta de referencia. Sitio oficial: iperf.fr.

Necesitás dos máquinas: una corre como servidor, otra como cliente.

# En el servidor
iperf3 -s

# En el cliente
iperf3 -c IP_DEL_SERVIDOR -t 30 -P 4

Esto mide TCP durante 30 segundos con 4 streams paralelos. Para medir subida, agregás -R (reverse).

Casos de uso:

• Validar si un enlace cumple su capacidad nominal contra un servidor propio.
• Probar entre dos sucursales sobre VPN.
• Comprobar si el router del cliente está saturando CPU bajo carga.

Hay servidores iperf3 públicos pero conviene usar uno propio o de un partner conocido para que la medición no se contamine con la red de un tercero.

Diagnóstico por síntoma

”VoIP se entrecorta, pero Speedtest da bien”

Probable jitter alto o packet loss bajo pero sostenido. Speedtest no lo detecta porque mide ráfagas cortas. Ejecutá:

ping -c 1000 -i 0.2 8.8.8.8

(1000 paquetes a 5 por segundo, simulando un flujo VoIP). Mirá mdev y % packet loss.

”El navegador anda lento pero descargas grandes van rápido”

Probable problema de DNS, no de capacidad. Probá cambiar a 1.1.1.1 o 8.8.8.8 y volvé a medir. Si mejora drásticamente, era DNS.

”Las videollamadas se cortan a horas pico”

Probable congestión en el ISP. Corré MTR sostenido a un destino conocido durante 10 minutos a las 21:30 y revisá si hay loss en los hops del proveedor que no aparece a las 11 am.

”Wi-Fi anda mal, cable bien”

No es internet, es Wi-Fi local. Causas frecuentes: interferencia de canales 2.4 GHz, distancia al AP, AP residencial colapsado. Esa es una nota aparte.

Qué documentar antes de reclamar al proveedor

Cuando llamás al ISP, ya con datos, el reclamo cambia de tono. Llevá:

1. Plan contratado (capacidad nominal y garantizada).
2. Tres mediciones de Speedtest en distintos momentos.
3. Salida de ping (1000 paquetes) con métricas de loss y mdev.
4. MTR sostenido al destino donde duele (servidor de mail, central VoIP, etc.).
5. Hora exacta y duración de los eventos problemáticos.

Con eso, no podés escuchar “todo está bien de nuestro lado” sin que te digan en qué hop específico.

Conclusión

Medir internet no es difícil ni caro. Las herramientas son gratis y los conceptos —latencia, jitter, packet loss, throughput— son cuatro. Lo que cambia el resultado de un reclamo es mostrar números reales en vez de adjetivos. Una hora invertida en MTR sostenido te ahorra discusiones interminables con la mesa de ayuda.

Fuentes y referencias

• Wikipedia — Network performance
• Wikipedia — MTR (software)
• iperf3 documentation
• Wikipedia — Ping (networking utility)

Fuentes

• Wikipedia — Network performance
• Wikipedia — MTR (software)
• iperf3 documentation
• Wikipedia — Ping (networking utility)