Ping alto, latencia

Buenas ILYAZZ 

Por lo general suelo no estar nada de acuerdo con lo absurdo que suelen ser las respuestas que suelen dar los proveedores de servicio/contenido, te diré que 1 de cada 100, son mentiras baratas para tirar la pelota a otro lado.

Primera traza:

En este caso hay dos problemas fundamentales, y repito esto es como siempre solo válido para el destino en cuestión, otro destino implica otras rutas otros valores otro todo.

El primero, y como te han dicho correctamente, hay jitter y pérdida de paquetes en el primer salto, algo habitual si usas un enlace WIFI:

192.168.1.1 - 1 | 502 | 501 | 1 | 5 | 68 | 4

No son datos extremadamente malos créeme, WIFI puede darte valores mucho mucho peores. Aun así es un problema, obviamente. Una conexión estable por cable debería de darte siempre 0% en pérdidas y un jitter mínimo, es decir, que la diferencia entre el menor valor (1) y la media (5) sean lo más similares posible. En el primer salto ya hay una diferencia de 4ms, lo que indica que los 68ms de pico no es un pico aislado. No pasa nada por tener un pico aislado ojo, ese valor podría ser de 100ms y no pasaría nada si el jitter fuese mínimo. En este caso hay una desviación de 3ms, que no es mucho, pero claro, es solo el primer salto, y encima con pérdidas.

Si esa prueba fue por enlace WIFI y no con cable directo, ya tienes el primer problema localizado. Si fuese por cable directo al Router, tendríamos que investigar algo más tu red, si hay un switch, otro dispositivo bla bla bla.

El segundo problema, viene en un salto considerable:

| 5.53.7.10 - 0 | 506 | 506 | 30 | 36 | 137 | 32 |
| 213.140.35.238 - 1 | 502 | 501 | 94 | 100 | 180 | 111 |
| 94.142.117.81 - 0 | 505 | 505 | 133 | 139 | 242 | 136 |

Vemos un incremento importante de latencia. A priori es un buen incremento y podría sonar alarma, lo que pasa es que en el salto del medio acabamos de saltar el atlántico. No es un mini salto, es un cacho de salto. A día de hoy casi todo el cableado del planeta (infraestructura de Internet general) es fibra, y aunque la velocidad de transmisión es inmensa, cercana a la de la luz, la latencia sigue existiendo por recorrido. Yo uso un valor "medio" de fabricación casera, en la que digo que son unos 0.4ms por cada 100km. recorridos. Así que si recorriésemos unos 8000km que es en línea recta madrid-brasil, solo en distancia tendríamos una pérdida de 32ms. Repito... línea recta, y obviamente de línea recta tiene poco. Simplemente cruzar el atlántico puede meterte 60-70ms entre una cosa y otra, a eso cuenta lo que restaría para llegar al destino, y la latencia acumulada de todos los saltos anteriores. Créeme, es mucho peor si tienes que pasar por Japón, no es raro que la latencia se vaya a 200-300ms

Esto tampoco lo podemos evitar, al menos en este caso.

----

La segunda traza es  diferente, aunque ilustra los mismos problemas en el  primer salto:

| 192.168.1.1 - 1 | 1195 | 1194 | 1 | 4 | 304 | 3 |

Si te das cuenta, aunque aquí haya un pico de 304, no es demasiado relevante, ya que la desviación de la mínima y la media tampoco es muy grande. Sí, significa que en un momento dado un paquete se salió de la gráfica... en un juego sería algo así como que de pronto notas un tirón importante, y tienes uno de esos cada 10-20 min. En juegos puede ser crucial si en ese instante estabas haciendo algo crítico, pero a efectos generales es irrelevante porque es algo puntual, y eso puede pasar siempre aunque sea por cable. Obviamente por WIFI es mucho mucho más probable.

También tenemos otro "problema" de latencia. En este caso en otro punto totalmente diferente a la otra traza, y por razones en apariencia diferentes también:

| ae5.cr0-mad5.ip4.gtt.net - 0 | 1199 | 1199 | 3 | 8 | 317 | 56 |

| ae22.cr11-fra2.ip4.gtt.net - 6 | 988 | 935 | 209 | 532 | 1221 | 341 |

He puesto esos dos saltos. En el primero de ellos vemos que el tráfico es bueno, sin contar con el  problema que arrastramos de WIFI del primero. Estamos en la red de GTT, con lo que Movistar no puede hacer nada ni controla nada en dicha Red, ambos saltos son de GTT.

Y de pronto, en el  siguiente nodo, vemos que se dispara el % de pérdida de paquetes, y la latencia. Fíjate ahora que pasa con el Jitter!! mínima de 209 y media de 532, una desviación enorme. Eso nos dice que el pico de 1221ms que aparece no es un pico puntual, sino que hay una fluctuación muy grande en ese nodo.

La pérdida de paquetes real, al igual que la latencia, hay que tener mucho cuidado. Porque muchos nodos de red realmente funcionan bien, y simplemente discriminan el tráfico ICMP que es el protocolo que se usa para estas pruebas, y que no tiene impacto en el tráfico real. Es decir,  porque en ese nodo diga eso no podemos creernos lo que dice. Hace falta mirar el destino final para ver si esos datos que tenemos en ese salto se pueden correlacionar:

| ae22.cr11-fra2.ip4.gtt.net - 6 | 988 | 935 | 209 | 532 | 1221 | 341 |

| 46.33.77.6 - 6 | 988 | 935 | 177 | 532 | 817 | 340 |

| core24.fsn1.hetzner.com - 37 | 490 | 313 | 206 | 537 | 757 | 580 |

| ex9k2.dc8.fsn1.hetzner.com - 5 | 1004 | 955 | 183 | 532 | 796 | 353 |

|static.41.127.201.138.clients.your-server.de - 6 | 988 | 935 | 180 | 530 | 816 | 344 |

Y vemos que si. La pérdida de paquetes se mantiene desde entonces, la latencia mínima/media mas o menos también. Date cuenta que los tracer/ping por cuestiones estadísticas salen así, es decir que un salto anterior o siguiente puede parecer tener valores ligeramente mas altos o bajos, pero es que no podemos lanzar un ping/tracer indefinidamente :). Por eso recomiendo siempre al menos 500 paquetes para tener valores más estabilizados.

En cualquier caso vemos que los valores finales muestra un "problema" similar que el salto negro, con lo que podemos afirmar que el salto en cuestión de GTT no es una discriminación de ICMP, sino que en ese nodo hay un problema REAL, y que obviamente GTT tendría que mirar, si es que no lo sabe ya.

Así que en las dos trazas que pones, vemos 3 problemas en total. Tu conexión al Router que posiblemente sea por WIFI, y luego dos problemas diferentes de diferentes situaciones, el primero por tener que llegar a Estados Unidos, otro por un nodo en mal estado de GTT