Buenas Hanzz0
Perdona compañero, fui yo mismo quien te pedí que hicieses las pruebas pero se me pasó el hilo y lo acabo de ver. Te contesto si me lo permites a los mensajes previos, sobre todo sobre tus dos capturas de WinMTR.
En primer lugar, por tu contestación veo que hay un pequeño error de concepto, que siempre hay que explicar, que es en esencia como funciona un ping o un tracert. Y esto es fundamental, porque sin tener ni idea de esto puedes estar viendo una cosa, y ser otra totalmente. Para no entrar mucho en detalle y que el post no sea kilométrico, digamos que ambos tracer/ping hacen uso de un protocolo especial llamado ICMP, y que e usa para diagnóstico de red. Es nuestra mejor herramienta que tenemos para esto como usuarios. Este protocolo funciona de un modo "sencillo". En el caso de PING, un usuario lanza un paquete especial ICMP llamado Echo Request, y este induce que el receptor responda con un ICMP Echo Reply. En caso de tracert es algo diferente, se juega con el valor TTL de los paquetes que por obligación un Router descarta un paquete cuando el TTL llega a cero y responde al origen con un ICMP de TTL agotado... de este modo un tracer nos permite "descubrir" los nodos intermedios.
Vale, por qué es esto importante? Porque cualquier nodo o destino puede bloquear completamente las respuestas ICMP, o priorizarlas, o permitir 1 de cada 5 o... Por eso muchos muchas veces interpretan una pérdida de paquetes o una latencia disparada de un nodo particular como un problema.... y simplemente ese nodo está retringiendo de algún modo el tráfico ICMP por cuestiones de eficiencia. Pero eso significa que no nos podemos fiar de los ping/tracert?? Si podemos, pero con cuidado, y teniendo en cuenta una máxima sencilla: Tanto la latencia como la pérdida de paquetes reales es acumulativa.
Esto es obvio, no?Si en el primer tramo tardas 100ms pero el segundo dice que 10ms... algo falla, porque para llegar al segundo has pasado antes por el primero, con lo que como mínimo tendría que ser un valor cercano a 100!! Con la pérdida de paquetes real ocurre lo mismo!! SI en un salto pierdes un 10% de paquetes, en el segundo salto se debe de reflejar más o menos un % similar, porque obviamente se han caído previamente.
Esta progresión nunca es exacta aun cuando no hay bloqueos ICMP por varios motivos, el principal es que internet es totalmente dinámico, y por otro lado el factor estadístico, de ahí que sea bueno enviar cientos de paquetes, para tener una visión más realista.
Google DNS
Bien, teniendo todo en eso en mente analicemos tus WinMTR. Vamos con el de Google, que es el primero que pusiste. nos 350 aprox. Lo primero es mirar la latencia y pérdida de paquetes finales, tanto la medida mejor como la media. ¿Por qué? Por que esto nos va a decir la latencia y pérdida de paquetes real (en principio). Por otro lado comparar la mínima con la media nos va a ayudar a ver como es el jitter, cuanto más parejo sea el valor, más estable será la conexión.
Tus datos a Google (8.8.8.8) :
destino final: Mejor 17, Media 17, 0% paquetes perdidos.
Es decir, resultados totalmente adecuados, no existe ningún problema en la red, incluso el jitter es una piedra, la estabilidad es absoluta. Sí vemos que ocurrió un 1% paquete perdido en tu conexión de tu equipo con el Router... este es real, pero el equipo lo reenvía, por eso no se arrastra esos paquetes perdido hacia Internet. De echo si miras a Google hay 346 paquetes, pero se supone que enviaste 342. Eso es porque tu equipo tuvo problemas en algún momento con una de las salvas y luego los reenvió. Dado que fueron casi 350 paquetes, pudo coincidir en cualquier momento cualquier proceso interno de tu equipo, una mini interrupción de tu adaptador de red o cualquier otra cosa del equipo que lo produjo. Esto no debería de tener impacto alguno final dado que como ves, en cualquier caso se reenvian automáticamente en tu red.
Con una latencia de 17ms a un servidor final, de nuevo, NADIE va a mover un dedo por ello. Google tiene Peer directo con Movistar, y es verdad que la latencia habitual para por ejemplo 8.8.8.8 suele rondar algo más por los 10-15ms, algunos dicen que incluso han llegado a 5ms... yo eso jamás lo he visto. Pero en cualquier caso 17ms no hace sonar ningún tipo de alarma o incidencia, se considera algo totalmente normal. Dependiendo de día, hora, momento... el peer simplemente puede estar ligeramente más cargada o menos, o la centralita o... pero esos valores en cualquier caso se consideran normales.
RIOT
Bien, con RIOT tenemos un problema de base bien conocido, puedes mirar en Internet, en este mismo foro o donde sea. Por el motivo que sea, que yo sepa no existe explicación oficial de RIOT, estos ocultan TODO lo que pasa en su red. Una vez el tráfico entra en su red, sus nodos/servidores están configurados para no responder con paquetes ICMP, lo que hace que sea imposible saber que pasa con la latencia o los paquetes perdidos dentro de su red. Lo único que podemos saber es lo que pasa justo en el punto anterior.
¿Como sabemos esto? Muy fácil. La parte de descubrimiento de nodos la hace tracert. Este lo que hace es enviar un paquete con TTL1, luego TTL2, luego TTL3... así va forzando a que cada vez que un nodo lo rechace por TTL envíe de vuelta un ICMP de TTL excedido. El truco es que ese ICMP tiene la IP de dicho nodo!! Con lo que así estas herramientas pueden crear un mapa de todos los saltos por los que pasan los paquetes. Dicho de otro modo, primero tu equipo manda un TTL1, le llega a tu Router, lo procesa, resta 1 al TTL, como es cero responde con ICMP TTL excedido, tu equipo ya tiene la IP del primer salto. Ahora manda uno con TTL2... el Router le resta 1, como no es cero lo pasa... llega a la centralita, le resta 1, llega a cero... lo descarta y te manda de vuelta el ICMP TTL excedido con su IP. Y esto se repite hasta que tu equipo recibe la respuesta de TTL inválido por la IP que tu pusiste de destino. Pero que pasa si un nodo intermedio no está configurado para responder?? Simplemente para esta herramientas ese host está caído o no existe o no responde, y lo que hace es simplemente mandar otro con un TTL+1... ese a lo mejor no estaba configurado para responder, pero el siguiente a lo mejor sí!! Por eso ves en las trazas algunos nodos intermedios que dicen didrectamente no response from host y 100% de pérdida. Realmente no es que exista una pérdida del 100%, es que esos nodos están configurados para no responder con paquetes ICMP TTL cuando lo descartan.
Pero exista un problema añadido... que pasa si a partir de uno en concreto, de ahí hasta el final están configurados para no responder a estas peticiones hasta el destino final. Pues lo que hace RIOT y lo que vemos, que llega un momento que a partir de ahí todo es no response. Realmente el destino final podía ser algo tan próximo como el mismo salto 7, o podría ser el 10, o podría ser el 50!! WinMTR/pingplotter... no puede saber esto porque el propio destino final no responde con paquetes ICMP, con lo que el programa intenta ver si hay otro después. Por eso normalmente se configuran para cortarlo después de X saltos
La cuestión es que ahí no podemos saber el destino que salto realmente es. Solo podemos coger como cierto el último valor conocido real, que es el salto 6, que es el nodo previo a entrar en la red de RIOT. En ese puntolos datos que tenemos son los siguientes:
Tus datos a RIOT (162.249.79.1):
Mejor: 16, Media 16, pérdida de paquetes 0. Es decir, no podemos saber que pasa más allá porque RIOT nos lo oculta, pero si sabemos que hasta ese punto exacto la conexión era perfecta. ¿Y que pasó después? No lo sabemos, no tenemos datos de los nodos ni la red de RIOT, ni del servidor final, bloquean la respuestas ICMP, con lo que no podemos conocer las IPs intermedias, ni tampoco la latencia real al destino por medio de PING
¿Y esto es legal? Sí, totalmente, porque el tráfico ICMP es de diagnóstico, un proveedor de contenido/servicios no tiene por qué configurar sus dispositivos para responder. Tu propio Router por ejemplo tiene reglas internas para permitir o impedir las respuestas PING, o para restringirlas si te envían constantemente un ping sostenido.
¿Asumimos que es mano negra por parte de RIOT y que si lo ocultan es para ocultar cualquier deficiencia en su red? ¿O simplemente lo hacen por eficiencia y para impedir que cualquier persona literalmente bombardee parte de su red lo que provocaría teóricamente una degradación en su red y servidores? Pues como decía esa respuesta oficial no la tenemos, que yo sepa. Lo que sí sabemos es que RIOT lleva realizando esta práctica años.
Y esto es un problema importante, porque yo te puedo asegurar que es lo que pasa hasta el salto 6 donde todo era adecuado, pero no tengo la menor idea que ha pasado luego. Pasó algo o no pasó nada? Ni idea. Un problema en el servidor final? en un nodo de ellos? Ni idea. A lo mejor no pasó absolutamente nada y no es siquiera un error de transmisión sino de input lag, o un cambio en el netcode o... da igual, únicamente se puede teorizar, porque la única que podría respondernos a eso sería RIOT... y por experiencia que ha pasado otras veces sus técnicos lo que dicen es alto tan absurdo siempre que da risa. Lo que te diría el técnico de RIOT sería:
"Como se puede ver en el salto 4 y 5 tienes una pérdida de paquetes total y eso es tu ISP (Movistar en este caso) y habla con ellos"
Esto es gracioso por muchos motivos, y siempre que dicen eso lo único que dejan ver o que te engañan o que no tienen ni idea de lo que hablan. Si eso fuese cierto, no habría salto 5, si en el salto 4 cae el 100% de los paquetes.... se acabó la partida, no hay más traza. Por otro lado, por si fuese poco, si ese fuese el problema estarían automáticamente dando por sentado que en su red pasa exactamente lo mismo... puesto que el problema es el mismo.
Obviamente ni lo uno ni lo otro, los nodos 4/5 bloquean simplemente las respuestas ICMP, esto es habitual en las trazas... en la otra de google eran 3 los que los bloqueaban, no es algo raro. Lo que es raro es que lo haga toda una red en todos sus nodos. A veces no son bloqueos completos, son parciales, y salen números como una pérdida de paquetes de un 10 un 50... pero sabemos que no es real si luego vemos un salto más adelante que marca claramente 0%.
Lo que sí vuelve a aparecer un 1% en tu red local de nuevo... no es significativo pero si peculiar que aparezca en ambas trazas... como recomendación te daría que lo realizases a cualquier destino en modo de fallo con conexión a la red por si tienes alguna suite tipo AV/seguridad que está perjudicándote ligeramente en ese punto. Que repito, no debería de tener un impacto real para jugar ni para nada, pero si existe dicha anomalía... y en cualquier caso está en tu PC
---------
¿Resumen de todo lo anterior? No tengo la menor idea del problema que puedas tener, pero las trazas son perfectas. Cualquier especialista que sepa mínimamente interpretarlo simplemente recoge esos datos y los guarda en el cajón. Y créeme que puede sonar rudo, pero se escale o no se escale, le llegue a quien le llegue, con esos datos Movistar ni ningún otro ISP va a hacer nada... porque no hay nada que solucionar. Al menos con esos datos, repito, Movistar sólo puede actuar en su propia red, y dichas trazas no muestran error alguno.
Aun cuando cualquier megaprefesional que se dedique a ello pensase que esa diferencia de latencia en red es enorme, con total independencia de que no hay estudios doble ciego que lo avalen por debajo de cierto umbral, desde el punto de vista de Internet no es una anomalía ni se ve como tal. El tráfico de toda Internet fluye bajo las mismas normas, tu tráfico para jugar corre en paralelo con el tráfico de ver vídeos o enviar mensajes instantáneos, no hay diferencia en él, lo único que cambian son rutas, redes, nodos intermedios... por destinos diferentes y servidores destinos diferente, nada más. Otra cosa totalmente diferente y que por supuesto habría que escalar y solucionar, sería un nodo con problemas, caído realmente, irregularidades constantes en un punto... pero nada más.
Internet es dinámico, en cualquier momento, hora del día, cualquier nodo de cualquier punto de cualquier red del mundo puede sufrir una subida/bajada dentro de parámetros nominales, que pueden ser en algunos casos bastante amplios. Y no me refiero ya a la distancia, que esa la física manda y es lo que hay, sino que los intercambiadores, los peer, los... todo eso induce latencia que depende como digo del momento, lugar, totalmente dinámico. Si solicitásemos que nos diesen los tiempos en micro segundos en vez de milisegundos, no habría una sola medida igual, y muchas de ellas variarían enormemente de otras para los mismos nodos, y más a un a diferentes horas o días.
Consejo? No te obsesiones. Créeme que no vas a jugar mejor/peor por tener 19ms o 25ms, a esas diferencias afecta más incluso lo que hayas comido o cualquier proceso de fondo que tenga el equipo que esos 6ms de latencia por transporte. Solo la latencia en mostrar el contenido, aun usando tecnologías como nVidia Reflex y otros, inducen mucha más latencia. Solo por poner un ejemplo simple... pones RIOT, así que posiblemente hablemos de LoL o Valorant. De los dos, LoL lo descartaríamos directamente porque incluso latencias de 50ms serían imperceptibles, así que pongamos Valorant, puesto que son los Shooters donde se supone que los reflejos, monitores de alta frecuencia y otros se llevan el pastel. Bien, pues en Valorant, solo la latencia que induce tu propio sistema, que no Internet ni el servidor destino, puede rondar entre los 13-50ms dependiendo de un buen listado de factores (gráfica, nvidia reflex, Hz, configuración/IRQ del sistema...).
Esto daría para una explicación bastante más amplia... pero digamos que por lo general el "gamer" profesional suele estar en general. Un cerebro normal tiene un tiempo de reacción de unos 250ms, un cerebro de un profesional de esports entre los 150-200ms. El problema es que los juegos solo nos muestran la latencia de transporte... y para nivel profesional es paradójicamente lo de menos (a menos que se tenga un problema real de conexión). Si tienes una latencia de sistema total de, pongamos, 50ms (lag de sistema + lag de transporte) y un cerebro de pongamos 180ms, la bala empezaría a salir pasados 230ms más tarde... aun cuando bajases 10ms la latencia de transporte, estarías en 220ms. Sí, por supuesto sería una ventaja frente a un cerebro de normal de 250ms y una latencia incluso de 20ms = 270ms en juegos tipo FPS, pero a nivel profesional esa diferencia es irrisoria, se ve afectado infinitamente más por cuestiones tan sencillas como ajustar bien el equipo... y ojo con esto, es cierto que cierto componentes importan en el lag del sistema y que son más caros, pero en la mayoría de los casos el bocado más grande a nivel realmente competitivo es el ajuste fino del propio equipo, interno, como por ejemplo si se usan IRQ o MSI en cada una de las partes del sistema, si no hay recursos compartidos... etc etc etc.
Saludos compañero, espero haber puesto algo de luz en el asunto, entiendo que es algo complejo y que realmente esto daría para una conversación infinitamente más amplia que unas "pocas" letras... pero al menos para que estés tranquilo en cuanto a tu conxión a la red se refiere, y lo que puedas o no pensar de RIOT... que realmente aquí es donde está la madre del cordero. Si el tráfico llega perfectamente a sus puertas, y eso podemos verlo perfectamente en los tracert/ping... podemos asegurar que hasta ahí todo está bien... dado que no podemos saber lo que pasa ahora en la red de RIOT... pues cada uno que saque sus propias conclusiones.
