¿Qué es lo que realmente importa al probar dispositivos de red?

• La capacidad del dispositivo para ofrecer una buena experiencia de usuario final.
• La capacidad de la red.
• ¿Y perdiste esa partida por culpa del lag? ¿O al final la red no fue el problema?

Al menos así tienes a quién echarle la culpa… aunque tu puntería diga lo contrario. 😅

Nuestros productos y servicios de "testing" se centran cada vez más en estos indicadores clave de rendimiento, en lugar de enfocarse únicamente en métricas como el ancho de banda bruto y la latencia de paquetes individuales.

Pruebas QED: Quality of Experience Delivered

Este tipo de testing fue creado en el laboratorio de Excentis en estrecha colaboración con Domos hemos trabajado evolucionado nuestros métodos hasta llegar al nuevo enfoque QED actual. Con estas pruebas podemos establecer criterios de aprobación o fallo para un test. Cuando un "test" se aprueba, podemos estar seguros de que los dispositivos evaluados serán capaces de satisfacer al usuario final. ¿Lag o mala puntería? Nosotros tenemos los datos 😉 

Nivel 1: Mediciones básicas de latencia

Hace muchos años, incorporamos las mediciones de latencia en nuestro generador/analizador de tráfico de red ByteBlower.

Los informes muestran la métrica de latencia por flujo:

Esto fue un gran paso adelante.

En ese momento, ya podíamos mostrar la latencia mínima, promedio y máxima. El jitter indicaba qué tan estable era esa latencia.

Nivel 2: Resultados de latencia a lo largo del tiempo

Las mediciones básicas de latencia eran útiles, pero no ofrecían información sobre cómo evolucionaba la latencia durante la prueba.

Por eso introdujimos los resultados de latencia a lo largo del tiempo.

¡Nuestros datos sobre latencia siguen creciendo y aportando información más útil!

¿Preguntas? Contacta a un experto

En este gráfico, puedes ver el porcentaje del tráfico recibido y la latencia máxima correspondiente. Aquí se observa que el 90% de todo el tráfico se recibió en menos de 13 ms.

Estas gráficas también facilitan mucho la comparación entre diferentes flujos. Los flujos situados más a la izquierda son los que presentan la menor latencia.

Nivel Pro: QED

Las gráficas de latencia CCDF son una herramienta muy potente. Se puede aprender mucho con solo analizar una de ellas. Pero aún así, presentan algunas dificultades.

¿Todo estaría bien si el 99.9% del tráfico de red llegara en menos de 1 ms?

¡No necesariamente!

Imagina que estuviste jugando durante una hora. En segundo plano, los paquetes se transmiten de bajada y subida a un ritmo constante. Esto significa que, durante el 0.1% del tiempo (es decir, 3.6 segundos), la latencia podría haber sido mucho mayor a 1 ms, como 100 ms o incluso más. ¡E incluso podrían perderse paquetes!

El peor escenario sería que todos esos “paquetes defectuosos” se enviaran de forma consecutiva. En ese caso, el gamer que acaba de llegar a la final de la Copa Mundial de e-sports quedaría congelado durante 3.6 segundos, resultando en ser eliminado de la partida… y en una experiencia muy frustrante.

Para evitar este tipo de problemas, estamos introduciendo histogramas de latencia en el tiempo dentro de nuestra API. Ahora bien, podríamos generar un histograma por cada segundo de prueba… ¡pero no lo haremos! Un montón tan grande de gráficas sería muy difícil de interpretar.

Para facilitar la interpretación de estas mediciones, generamos un nuevo gráfico que muestra algunos percentiles claveque realmente nos interesan:

Para cada percentil podemos especificar un límite máximo de latencia permitido. Las zonas de latencia que superan ese límite se marcan con un color sólido. Esto genera automáticamente un fallo en la prueba.

Cuando no se superan los límites, podemos garantizar una experiencia óptima durante toda la partida.

En nuestra página de GitHub, ofrecemos un script de ejemplo que demuestra cómo puedes ejecutar tú mismo este tipo de pruebas. ¡También incluimos resultados de ejemplo!

¿Ya ha terminado el juego?

La historia no termina aquí.

El enfoque binario Aprobado/Fallado a veces resulta demasiado rígido. Si el resultado es un fallo, queremos saber rápidamente qué tan grave fue. Si es un aprobado, ¿con cuánto margen contamos? ¿Y qué pasa si queremos comparar distintos flujos? Esto será posible con Quality of Outcome (QoO).

Al definir un margen bajo y alto de latencia por percentil, es posible calcular qué tan lejos estamos del desastre (0% QoO) o de la perfección (100% QoO).

Actualmente se está preparando un RFC sobre QoO para su publicación.

Pero incluso esto no será la última palabra. ¡Nuevos retos aparecerán, y los superaremos!

En este artículo nos centramos en el gaming, pero también probamos videoconferencias, streaming de video y navegación web, utilizando patrones de tráfico realistas.

Integra las pruebas QED en tu red

La integración de pruebas QED en tu red puede aumentar significativamente la satisfacción de los usuarios, aportar a tu negocio una gran ventaja competitiva (USP) y además reducir los costos de soporte y resolución de problemas.

Hablemos de QED.

Descarga nuestro "white paper" ¿Es L4S la solución definitiva contra la latencia?

L4S (Low Latency, Low Loss, Scalable Throughput) promete revolucionar la experiencia en redes al reducir la latencia y el jitter incluso bajo alta carga. Esto lo convierte en una tecnología clave para aplicaciones sensibles como videojuegos, videoconferencias y otras de tiempo real.

Aun así, no resuelve todas las fuentes de latencia: factores como la gestión del acceso Wi-Fi siguen siendo críticos. Para aprovechar realmente L4S, es necesario combinarlo con una configuración adecuada de red y políticas de acceso que mantengan la calidad de la experiencia del usuario.

Descubre cómo descubrimos junto a Nokia Bell Labs todos los factores que interfieren para llegar a una latencia muy baja con L4S.

Descarga nuestra publicación