Buenas haze1
Contestando por citación.
En absoluto los hilos al respecto caen o se dejan en saco roto, todos hay que mirarlos y tratarlos de forma totalmente diferente, porque cada uno por lo general no solo corresponde a destinos diferentes, sino que momentos diferentes desde ubicaciones diferentes. Hilos sobre latencia hay a patadas, eso no quiere decir que a veces sean realmente problemas o incidencias que existen, y otras muchas veces no sea un problema real, al menos en cuanto a tránsito se refiere. Otras veces por otro lado si que existe un problema en tránsito pero no está en la red del ISP, con lo que poco o nada se puede hacer. Pero claro que son importante estos hilos, y claro que hay que analizarlos, porque si el problema existe y está en la red del ISP, hay que reportarlo para que lo solucionen, y créeme que soy el primero que cuando la culpa es del ISP es del ISP y tienen que arreglarlo.
Bien dicho todo eso y contestando un poco a tus cuestiones. Aquí lo más importante son los datos de tránsito, y eso nos lo marca en este caso WinMTR. Por desgracia está cortado, no vemos el final, con lo que no te puedo dar una respuesta más allá del último nodo que aparece en tu imagen. No obstante si te puedo contestar a tenor de lo que se ve.
Esto lo he repetido mil veces, tanto la latencia como la pérdida de paquetes real es acumulativa. He puesto muchos ejemplos, el último fue imaginar que 100 personas hacen una carrera de 100km donde cada 10km hay un punto de control donde se cuentan a las personas que pasan. Si en uno de los tramos se caen 10 personas, el siguiente control va a contabilizar obviamente 10 personas menos. Si en ese siguiente tramo no se cae nadie, cuantas personas va a contar el siguiente control? Pues las mismas que contó el anterior, obviamente. Y si se caen en ese ultimo tramo otros 10, el punto de control contaría al menos 20 bajas.
Cuando vemos en algunos nodos salteados "perdidas de paquetes" que luego no se cumple en los siguientes, no es por exista tal pérdida, sino porque esos nodos discriminan las contestaciones ICMP, que es el protocolo de control que usa ping/tracert. Esto es habitual, y no afecta absolutamente ni a la latencia ni a los paquetes perdidos reales.
Te pongo mi winmtr realizado ahora mismo a la misma dirección:
| WinMTR statistics |
| Host - %% | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------|------|------|------|------|------|------|
| Router - 0 | 539 | 539 | 0 | 0 | 14 | 0 |
| 192.168.144.1 - 6 | 452 | 429 | 1 | 1 | 14 | 1 |
| 157.red-81-41-225.staticip.rima-tde.net - 0 | 539 | 539 | 1 | 2 | 45 | 2 |
| No response from host - 100 | 1380 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 1483 | 0 | 0 | 0 | 0 | 0 |
| ae-0-400-grtmadde3.net.telefonicaglobalsolutions.com - 0 | 539 | 539 | 8 | 9 | 60 | 8 |
| 176.52.248.172 - 1 | 535 | 534 | 7 | 10 | 50 | 8 |
| mad-b3-link.telia.net - 65 | 287 | 102 | 0 | 8 | 11 | 9 |
| prs-bb1-link.ip.twelve99.net - 0 | 539 | 539 | 33 | 33 | 73 | 33 |
| ffm-bb1-link.ip.twelve99.net - 0 | 539 | 539 | 43 | 43 | 74 | 43 |
| ffm-b11-link.ip.twelve99.net - 0 | 539 | 539 | 43 | 44 | 116 | 43 |
| marbisgmbh-svc085894-ic376067.ip.twelve99-cust.net - 0 | 539 | 539 | 45 | 46 | 90 | 54 |
| No response from host - 100 | 1266 | 0 | 0 | 0 | 0 | 0 |
| 195.82.158.81 - 0 | 539 | 539 | 45 | 45 | 76 | 45 |
Fíjate en todos los puntos que he puesto en negrita. En el segundo salto que es la centralita dice que 6%, dos más allá dice que un 100%, luego por ahí un 1, un 65... y obviamente muchos 0, sobre todo el final, que es el que nos importa. A ver, si se perdiesen el 100% de paquetes en algunos de los saltos anteriores... como diablos iban a llegar paquetes al final??
Simplemente esos puntos están discriminando el tráfico ICMP, y es normal. El nodo final me vale para saber si existe realmente una pérdida de paquetes que pueda ser real o no, y la latencia media final. En mi caso tengo 0% y 45ms de media. Es decir, unos datos muy buenos. (no te fijes en los paquetes enviados que muestran el doble en algunos nodos, pero es por el uso de IPv6, lo tenía activado en WinMTR)
El input lag claro que es importante en cualquier juego, pero este por lo general se ve afectado en mucha mayor medida por el netcore del propio juego. Si el servidor en el juego te dice cerca de 100ms, pero winmtr te dice cerca de 50ms, por ejemplo, simplemente el propio servidor de juego o el PC (cualquiera de los dos extremos) se está comiendo un 50% en procesar los datos del propio juego. Piensa que un ping/tracert son paquetes mínimos, no requieren procesado por parte de los extremos. En los puntos intermedios da igual porque lo que hacen es reenviar y listo, pero los puntos de inicio/destino tienen que procesar los datos, ya sean Firewall, congestión, o como he dicho el netcode que usen.
No pudo decir mucho más te repito pq no se ve la latencia final en winmtr, pero presupongo que será similar a la mía. Si quieres ponerlo completo, perfecto :), pero por lo que podemos ver, no existe problema alguno ya no solo en la red de Movistar, sino en la transmisión de los datos desde el origen al destino. Repito, en la transmisión de los datos.
