Cómo mide esta prueba tu conexión
Esta página describe exactamente qué envía PingPacketTest.com, cómo eso se convierte en los tres números de la página principal y, en la última parte, qué no pueden decir esos números. Si lees solo una parte, que sea la última.
Qué envía realmente la prueba
El navegador abre un DataChannel de WebRTC hacia uno de los servidores de medición y envía paquetes pequeños. El canal usa ordered: false y maxRetransmits: 0: el navegador no puede reenviar un paquete ni retener uno porque falte otro anterior. Es UDP real, el mismo transporte que usan casi todos los juegos en línea.
Cada paquete lleva un número y su hora de salida, con el tamaño de paquete del juego elegido. El servidor solo lo devuelve tal cual. La ida y vuelta se mide entera en tu navegador con un solo reloj. Un paquete cuyo eco nunca llega cuenta como perdido.
Por qué un test de velocidad no responde esta pregunta
Un test de velocidad mide ancho de banda por TCP, que está hecho para esconder justo lo que buscas: un paquete perdido se reenvía en silencio y al final queda una velocidad un poco menor.
Un juego no hace eso. Envía una posición a ritmo fijo y sigue; una actualización perdida nunca se reenvía. Por eso una línea puede pasar todos los tests de velocidad y aun así causar rubberbanding.
Tick rate: por qué el juego elegido cambia la medición
Un servidor de juego avanza el mundo en pasos fijos, los ticks. Ese ritmo decide con qué frecuencia pasan paquetes por tu línea y cuánto cuesta un retraso: a 128 ticks, 60 ms de ida y vuelta son casi ocho actualizaciones; a 20 ticks, apenas una.
Elegir un juego aquí cambia el ritmo de envío y el tamaño de paquete de la propia medición. El ritmo de cada título, su fuente y si está verificado o estimado están en la base de datos de tick rates.
Dónde están los servidores de medición
Son cuatro: Nueva York, San José, Fráncfort y Singapur. Tu navegador mide por defecto contra el más cercano; puedes cambiarlo para revisar una ruta concreta. El servidor usado aparece en cada resultado, porque un ping sin destino no significa nada.
Cómo se calculan los números
El primer segundo no cuenta. Cada medición empieza con un segundo de calentamiento: se envían paquetes, pero no se cuentan. Los primeros paquetes de una ruta son más lentos, y ese costo es del establecimiento de la conexión, no de tu línea. Solo vale al inicio: un corte a mitad de la medición aparece completo.
El ping es una mediana, con todo el rango detrás. El gráfico dibuja un punto cada 100 ms; el punto es la mediana de los paquetes de ese tramo y la banda sombreada va del más bajo al más alto. Nada se suaviza.
La pérdida de paquetes nunca se promedia. Un solo paquete perdido dibuja su marca en todos los niveles de zoom. Un paquete contado como perdido que llega después recupera su estado: llegó tarde, no se perdió.
El jitter se mide en ventanas fijas de un segundo (desviación estándar de las idas y vueltas de cada segundo, promediada). Así la misma línea marca el mismo jitter con cualquier tick rate. Una ida y vuelta de más de 1000 ms cuenta como pérdida.
Cómo se calculan el veredicto y el percentil
El veredicto toma el peor de los tres números, no el promedio. 20 ms de ping con 2 % de pérdida no es una buena conexión. Los límites de jitter salen del tick rate (medio tick para «bueno», un tick para «jugable», con tope de 15 y 30 ms); los de ping son un criterio publicado aquí: 30/60 ms desde 100 Hz, 40/80 ms con 60–64 ticks, 60/100 ms con 30 ticks, 80/150 ms por debajo. Para la pérdida, el límite es igual en todos: más de 1 % no es suficiente.
El percentil te compara con las mediciones hechas aquí, no con internet. Quien abre un test de pérdida de paquetes no es una muestra al azar: muchos vienen porque algo ya va mal.
Qué significa la línea Tipo de NAT
Durante la medición, la línea de estado muestra el tipo del par de candidatos ICE que se usa de verdad: host para un camino público directo, server-reflexive para un paso a través de un NAT que permitió una ruta directa, relay para una conexión por intermediario. Se muestra como Abierto, Moderado y Estricto, las palabras de los menús de consola. Un navegador no puede leer el valor de tu consola; esta es la observación equivalente.
Cómo se cuentan los cortes y la disponibilidad
A partir de un minuto, la herramienta dice qué hizo la línea durante ese tiempo. Un corte es un tramo de al menos un segundo completo en el que cada ventana de 100 ms perdió al menos un paquete. La disponibilidad es la parte del tiempo medido fuera de esos tramos. Se calculan una vez, al final, y se guardan con el resultado.
Lo que esta prueba no puede decir
Medimos la ruta a nuestro servidor, no al del juego. Si la ruta a Fráncfort está limpia y tu juego se traba, el problema puede estar entre tu proveedor y el centro de datos del juego.
Una ida y vuelta no dice en qué sentido se perdió un paquete. Y no es un traceroute: prueba pérdida en la ruta completa, sin señalar el tramo culpable.
Si UDP está bloqueado, la prueba usa TCP. El ping sigue siendo útil, pero la pérdida sale más baja que la real porque TCP reenvía. Lo mismo vía relé (TURN): el camino es más largo que tu ruta real.
Medimos tu conexión tal como está, con todo lo que la usa. Una descarga, una consola actualizándose o un stream en casa entran en el resultado. Si una medición sale mal, repítela con todo lo demás apagado.
Un navegador no es un entorno de tiempo real. Un equipo muy cargado o una pestaña en segundo plano pueden añadir algo de jitter que viene de tu dispositivo, no de tu proveedor.
No es un test de velocidad. Y nada en este sitio es una muestra al azar de internet: cada comparación publicada dice «de las pruebas hechas aquí».
Para seguir
La base de datos de tick rates lista cada juego con el ritmo que envía, su fuente y su estado. Las estadísticas de pérdida de paquetes y las estadísticas en vivo están en inglés. La prueba empieza en cuanto la abres.
Preguntas, correcciones o un error de método: info@pingpackettest.com.