Latencia, jitter y pérdida de paquetes: qué significa cada medida
Un resultado de descarga rápido no garantiza una llamada o una partida fluidas. El tráfico interactivo también depende de la latencia, de las variaciones de la latencia, conocidas como jitter, y de la pérdida de paquetes. Cada una describe un aspecto distinto de la conexión, así que mídalas por separado antes de cambiar de equipo o culpar a un servidor.
Tres mediciones, tres preguntas distintas
La latencia es el tiempo que tardan los datos en viajar entre dos puntos. Un resultado de ping suele indicar el tiempo de ida y vuelta (RTT): el intervalo entre el envío de una sonda y la recepción de su respuesta. El jitter describe la variación entre retardos sucesivos. Unas respuestas que llegan en 20, 21, 90 y 18 milisegundos pueden tener una media aceptable y contener aun así un pico perturbador. La pérdida de paquetes significa que una sonda o su respuesta no llegaron dentro del límite de tiempo de la prueba. La congestión es una causa posible; el filtrado deliberado del tráfico de diagnóstico es otra.
Estas medidas se influyen entre sí, pero no son intercambiables. Un enlace capaz de transferir rápidamente un archivo grande puede acumular una cola en el router durante una subida y retrasar los paquetes cortos que usa una llamada. Una única respuesta lenta de un router intermedio es una prueba débil de un problema de extremo a extremo: los routers pueden dar baja prioridad a las respuestas ICMP mientras reenvían el tráfico normal.
Cómo hacer las pruebas, paso a paso
Envíe una serie de sondas al mismo destino con la herramienta de ping y traceroute. Anote el destino, la hora, el RTT mínimo y máximo y las sondas sin respuesta. Repita la prueba por Ethernet o desde otra red. Ejecute el test de velocidad por separado; el rendimiento y el retardo responden a preguntas distintas. Si la Wi-Fi presenta picos que Ethernet no tiene, investigue primero la calidad de la señal, las interferencias y los demás dispositivos de la red local.
Mantenga condiciones comparables: el mismo servidor, dispositivo, método y franja horaria aproximada. Compruebe tanto una conexión en reposo como una que esté realizando una subida grande. Un gran aumento del RTT bajo carga apunta a la formación de colas; es poco probable que cambiar solo el DNS lo solucione. Varias pruebas cortas a lo largo del tiempo son más útiles que una única captura de pantalla tomada durante un pico inexplicado.
Cómo interpretar los resultados en cada aplicación
No existe un umbral universal de jitter que haga buenas todas las partidas o llamadas. Las aplicaciones difieren en cómo almacenan el audio en búfer, se recuperan de las pérdidas y eligen las rutas de red. Las respuestas ICMP perdidas no equivalen automáticamente a paquetes multimedia perdidos. Si solo un servicio tiene problemas, examine las estadísticas y el estado de ese servicio. Un trazado de ruta puede ayudar a localizar un patrón, pero sus sondas pueden seguir un camino distinto del de la aplicación.
El RFC 792 describe los mensajes ICMP Echo que suele utilizar ping. Define el mecanismo, no una puntuación única de calidad para todas las aplicaciones. Compare los resultados repetidos con los síntomas que los usuarios notan realmente.