Lag en juegos, teletrabajo, etc

Buenas printertale 

Los datos son similares a los anteriores, latencia final, pérdida de paquetes real final, son datos totalmente adecuados.

En el primer caso tenemos (juego 1)

Destino Final: 0% paquetes perdidos, 32 de minima, 33 de media. Ni Jitter, ni latencia alta ni paquetes perdidos

En el segundo caso tenemos (juego 2)

Destino final: 0% paquetes perdidos, 40 mín y media. Ni jitter, ni latencia elevada ni paquetes perdidos.

-----------------------

Los nodos que haces referencia, creo que lo explique anteriormente, y es como funcionan estas herramientas: ping/tracert, ambas aprovechándose del uso del protocolo ICMP

Una herramienta tipo "PING", lo que hace es enviar un paquete especial ICMP de tipo Echo Request. Esto induce al destino (si no bloquea esas peticiones) a contestar con un ICMP Echo Reply. La herramienta que lo envía puede medir así el tiempo desde que envía el paquete Request hasta que recibe el Reply. El tiempo que pasa desde el envío hasta la recepción es lo que por regla general llamamos latencia. Realmente esto tan solo mide la latencia de transporte, no mide la latencia del procesamiento de los paquetes de tráfico real. Nos vale solo para tener una idea de lo que demoran los paquetes de datos en llegar a destino.

Una herramienta tipo "TRACERT", se aprovecha tb del protocolo ICMP pero de otro modo. Los paquetes IP tienen un campo llamado TTL o tiempo de vida. Cada vez que un paquete pasa por cualquier nodo de red (punto intermedio) su valor se decrementa en 1, si llega a cero lo descarta. Esto no tiene mayor problema, el secreto es que cuando un nodo o punto intermedio decrementa el valor en 1 y como resultado da cero y lo descarta, devuelve al origen del paquete un mensaje ICMP especial que indica TTL excedido. Dado que quien responde con dicho mensaje puede ser cualquier punto intermedio, podemos aprovecharnos de esto para localizar cada nodo/salto intermedio. Como? Pues una herramienta tipo tracert envía primero un paquete a destino con un TTL = 1. Al pasar por el primer nodo (nuestro Router por lo general) lo va a decrementar en 1, como es cero lo descartará y avisará al equipo que descartado por TTL, el equipo puede ver que el origen del paquete es el Router. Ahora envía otro con TTL2. En este caso el paquete pasa normal el Router, pero es el segundo salto el que al decrementar en 1, será cero. Ahora es ese segundo nodo quien envía el paquete ICMP al origen. La herramienta tiene ya por tanto 2 saltos, con sus IPs... y así sucesivamente hasta que quien le responde es precisamente la IP final.

Bien, cual es el problema? Realmente no hay ninguno, lo que pasa es que estas dos utilidades que se usan para realizar este tipo de estadísticas (pingplotter, winmtr...) dan por sentado que los nodos intermedios y finales siempre van a contestar de forma correcta con un ICMP Reply en el caso de ping o con un paquete de TTL excedido en caso de tracert. Y el 90% de las veces así es. No obstante, para evitar abusos y ahorrar anchos de banda, es habitual que nodos intermedios sobre todo bloqueen completamente o parcialmente estas respuestas. Y esto es una faena, porque nos impide tomar en ese nodo particular datos realistas. A veces es un bloqueo completo, estos son los más fácil de ver, cuando tenemos un nodo intermedio que dice 100% paquetes perdidos por ejemplo o no response from host. Otras veces son discriminaciones o moderaciones, bloquear el 10%, el 50%, el... cada nodo se configura de cualquier modo. La mayoría de los Router domésticos incluso suelen hacer esto tb en cierto modo con los ping.

--------------

Entonces si hay nodos que no son fiables, como podemos saber si realmente existen pérdidas de paquetes o latencias raras en esos nodos? Fácil. Si lo que nos importa es el comportamiento general, miramos el final, si el final dice 0% paquetes perdidos son 0% paquetes perdidos, porque antes ha tenido que pasar por todo lo anterior!! Si existiese una pérdida real de un 10% por ejemplo, ese 10% se iría arrastrando hacia abajo hasta el destino final. Lo mismo pasa con la latencia. SI un nodo dice que la latencia es de 500ms, pero el destino final es de 50ms, sabemos que ese nodo intermedio no le están llegando bien los ping, o simplemente los están filtrando a medias.

Esto es lo que pasa con los nodos que indicas de Movistar. Si ese 99% fuese real, o el 29 o el... todo ello se vería arrastrado hacia abajo, porque esto es una "cadena" a fin de cuenta, los paquetes para llegar al salto 10 tienen que pasar antes por todos los anteriores, y si alguno de ellos se han caído 4, esos 4 van a aparecer caídos igualmente en los siguientes. Piensa en una carrera en la que salen 10 personas a correr y diferentes puntos de control. Por el primer punto pasan los 10, en el segundo tramo se caen 2 y siguen 8. En el segundo punto de control por tanto se cuentan 8. Si se cae un tercero en el siguiente trammo el punto de control 3 va a contar 3 menos en total (2 del segundo y 1 del tercero). Cuando llegan a la meta de los 10 que salieron a lo mejor solo llegan 4, luego se contabilizan 4. Si miramos solo el destino final y llegan 4 de 10, no podemos saber donde se han caído. Por eso usamos estas herramientas, para que nos digan DONDE se han caído. En cambio, si el destino nos dice que de 10 que salieron llegaron 10, no se ha perdido nadie por el camino, en todo caso un punto intermedio ha contado mal o un participante llegó con mucho retraso y ya no lo contaron o... pero llegar llegaron los 10.

---------

No veo que exista ningún problema en transmisión de datos, ni en la red de Movistar, in en redes intermedias ni en destino final. Si esos problemas siguen presente en esos momentos, o es en el equipo de origen o en los equipos de destino, o que el destino, después de llegar los paquetes allí, estén por otro lado enrutando el tráfico por una red interna o cualquier historia similar. Pero en lo tocante a tus paquetes de datos desde que salen de tu equipo hasta que llegan a destino, cero problemas. Si existiese problema en ello, estas herramientas nos lo dirían o mostrarían pérdidas de paquetes reales arrastrados hacia abajo, o latencias altas, o un jitter muy elevado o... pero nada de eso pasa, ni siquiera existen picos altos estadísticamente consistentes.

Saludos.