Latencia y traza por hora

[velocidad]

Hace una semana cuando todavía no tenía fibra, un familiar se quejaba de que en el juego al que jugamos juntos le subía el ping dependiendo de la hora. Mientras que él (con fibra) por la tarde/noche tenía más de 150 de ping, yo con mi ADSL tenía 80.

Pense que esto podría deberse a un problema puntual o de su central, pero ahora que yo también tengo fibra el problema se repite.

En concreto la IP del servidor es esta: 159.100.232.114

Con ADSL el ping que tenía era este:

ping 159.100.232.114 -t

Haciendo ping a 159.100.232.114 con 32 bytes de datos:
Respuesta desde 159.100.232.114: bytes=32 tiempo=83ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=89ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=83ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=85ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=87ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=87ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=89ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=88ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=83ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=90ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=86ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=84ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=83ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=88ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=83ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=85ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=86ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=87ms TTL=54

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 18, recibidos = 18, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 83ms, Máximo = 90ms, Media = 85ms

y también con ADSL, pero en Domingo (día de "posible" saturación del servidor):

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 100, recibidos = 100, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 92ms, Máximo = 93ms, Media = 92ms

Con la fibra sube entre las 19h y las  23h, y además es muy inestable:

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 100, recibidos = 100, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 75ms, Máximo = 155ms, Media = 93ms

---

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 1000, recibidos = 1000, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 78ms, Máximo = 169ms, Media = 114ms
---
Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 2209, recibidos = 2208, perdidos = 1
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 41ms, Máximo = 128ms, Media = 74ms

Fuera de este horario:

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 100, recibidos = 99, perdidos = 1
    (1% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 40ms, Máximo = 50ms, Media = 46ms

Mirando en la página de super-ping.com veo que la media de Europa es de 18ms (el servidor está en Inglaterra). Captura a las 22:30h cuando yo con fibra tenía 150 de ping.

Al ver esto pensé tambien que podría haber un problema con la linea, pero después de lanzar ping a Sony en Japón, veo que ese no es el problema:

Sony.jp:
========
Estadísticas de ping para 80.239.237.187:
    Paquetes: enviados = 100, recibidos = 100, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 63ms, Máximo = 64ms, Media = 63ms
---
Estadísticas de ping para 80.239.237.176:
    Paquetes: enviados = 1000, recibidos = 1000, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 53ms, Máximo = 68ms, Media = 53ms

Viendo esto hice una traza a la IP del servidor que da problemas para ver que pasaba, y estos son los resultados de dos trazas seguidas:

>tracert 159.100.232.114

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     2 ms     2 ms     2 ms  192.168.144.1
  3     3 ms     3 ms     *     157.red-81-46-6.customer.static.ccgg.telefonica.net [81.46.6.157]
  4     6 ms     3 ms     3 ms  86.red-81-46-8.customer.static.ccgg.telefonica.net [81.46.8.86]
  5    17 ms     3 ms     3 ms  et-15-0-0-1-401-grtmadpe3.net.telefonicaglobalsolutions.com [216.184.113.108]
  6     4 ms     4 ms     4 ms  te0-1-0-12-gramadix1.net.telefonicaglobalsolutions.com [213.140.43.252]
  7     5 ms     6 ms     6 ms  213.140.52.237
  8    37 ms    37 ms    37 ms  217.239.45.198
  9   103 ms   105 ms   105 ms  193.159.226.18
 10    83 ms    82 ms    86 ms  195.122.154.4
 11    86 ms    88 ms    89 ms  159.100.232.114

Traza completa.
__________________________________________________________
>tracert 159.100.232.114

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     3 ms     2 ms     2 ms  192.168.144.1
  3    39 ms     7 ms     6 ms  157.red-81-46-6.customer.static.ccgg.telefonica.net [81.46.6.157]
  4     4 ms     6 ms     6 ms  86.red-81-46-8.customer.static.ccgg.telefonica.net [81.46.8.86]
  5     3 ms     3 ms     3 ms  et-15-0-0-1-401-grtmadpe3.net.telefonicaglobalsolutions.com [216.184.113.108]
  6     4 ms     4 ms     4 ms  te0-1-0-12-gramadix1.net.telefonicaglobalsolutions.com [213.140.43.252]
  7     4 ms     6 ms     5 ms  213.140.52.237
  8    38 ms    37 ms    38 ms  217.239.45.198
  9    70 ms    69 ms    67 ms  193.159.226.18
 10    75 ms    67 ms    67 ms  195.122.154.4
 11    77 ms    69 ms    79 ms  159.100.232.114

Traza completa.

Aparentemenete hay un problema con el salto 3 y 5 (Telefonica), intenté hacer ping, pero una de las dos direcciones no responde, y con la otra pasa esto:

>ping 216.184.113.108 -n 100

Haciendo ping a 216.184.113.108 con 32 bytes de datos:
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=23ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=30ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=14ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=16ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=4ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=26ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=32ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=4ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=20ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=12ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=35ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=22ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=22ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=2ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61
Respuesta desde 216.184.113.108: bytes=32 tiempo=3ms TTL=61

Estadísticas de ping para 216.184.113.108:
    Paquetes: enviados = 100, recibidos = 100, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 2ms, Máximo = 35ms, Media = 5ms

Dado que a mi linea no le pasa nada, y parece que el problema esta en los servidores de salto, ¿podría darme algún moderador una solución a este problema? No puede ser que me pase a la fibra para tener más velocidad y mejore latencia, y que la latencia sea mejor solo a unas horas y peor a otras.

[Theliel]

Buenas @velocidad

En realidad tienes la solución delante tuya con los datos que buenamente has aportado. Por eso digo que ante problemas de lantencia siempre siempre siempre aportar datos, no de PING, esos en estos casos no aportan mucho interés, pero si los del tracert (pongo el último tuyo aquí para verlo más claro)

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     3 ms     2 ms     2 ms  192.168.144.1
  3    39 ms     7 ms     6 ms  157.red-81-46-6.customer.static.ccgg.telefonica.net [81.46.6.157]
  4     4 ms     6 ms     6 ms  86.red-81-46-8.customer.static.ccgg.telefonica.net [81.46.8.86]
  5     3 ms     3 ms     3 ms  et-15-0-0-1-401-grtmadpe3.net.telefonicaglobalsolutions.com [216.184.113.108]
  6     4 ms     4 ms     4 ms  te0-1-0-12-gramadix1.net.telefonicaglobalsolutions.com [213.140.43.252]
  7     4 ms     6 ms     5 ms  213.140.52.237 (Movistar)
  8    38 ms    37 ms    38 ms  217.239.45.198 (Deutsche)
  9    70 ms    69 ms    67 ms  193.159.226.18 (Deutsche)
 10    75 ms    67 ms    67 ms  195.122.154.4
 11    77 ms    69 ms    79 ms  159.100.232.114

Traza completa.

Bien, no hay ningún problema en los saltos 3 y 5, en absoluto!! el "problema" está en el salto 8 y luego en el 9, ambos perteneciente a Deutsche Telekom , que son los dos puntos donde el incremento de latencia es notablemente mayor. La tus paquetes abandonan la red de Movistar en el Salto 7, en el 8 ya está en sus dominios.

Como ves estando dentro de la red de Movistar la latencia es mínima, 4-6ms, y el problema aparece al saltar a su red. Incluso ya dentro de su propia red y saltar a otra, vemos en el salto 9 como vuelve a subir considerablemente de 37ms a 68ms, que sería otro incremento notable.

No hay nada que pueda hacer Movistar aquí, y poco que puedas hacer tú. En todo caso y en el mejor mejor de los casos Movistar podría ver que pasa con el Peering por si existiese algún problema en él, y como digo en el mejor mejor de los casos, pero quitando eso poco más, el problema está en la red de Deutsche. Que podría usar otra red a la de Deutsche para alcancer el destino?? No lo sé, eso sería mucho más complicado de ver y meterse en berenjenales mucho más complejos

Lo que está claro que el problema está en la red de Deutche, suelen ser temporales o debidos a saturaciones, pero...

Mi tracer es algo mejor que el tuyo a efectos generales (aunque mi latencia por Movistar es peor), pero aun así se evidencia lo mismo:

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms     1 ms    <1 ms  router.asus.com [192.168.2.1]
  2     2 ms     2 ms     2 ms  192.168.144.1
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4     9 ms     9 ms    10 ms  77.red-81-46-1.customer.static.ccgg.telefonica.net [81.46.1.77]
  5    26 ms     9 ms     9 ms  213.140.50.85
  6    14 ms     9 ms    10 ms  te0-0-0-6-gramadix1.net.telefonicaglobalsolutions.com [84.16.13.202]
  7    54 ms    11 ms    11 ms  213.140.52.239
  8    46 ms    42 ms    41 ms  217.239.44.2 (Deutche)
  9    46 ms    46 ms    45 ms  87.190.232.66
 10    46 ms    46 ms    45 ms  195.122.154.3
 11    45 ms    46 ms    45 ms  159.100.232.114

[velocidad]

Gracias por responder.

Aunque aparentemente el problema está en Deutsche Telekom, esto es solo un espejismo, por eso puse el resto de datos, con ADSL (también movistar esto no pasa). Y si te fijas en los 100 saltos de ping que he puesto de telefonica se ve claro el problema, pasa de 2ms a 30ms, y ese es uno de los cuatro saltos de Telefonica, si en el resto (que no he podido probar), pasa lo mismo, pues ahi lo tienes 30+30+30+30, 120 mas los 40ms normales, pues los 160ms que me están saliendo en esas horas.

En cualquier caso, problema existe, y dado los datos de super-ping.com todo apunta a un problema de Movistar (por si con los datos que he puesto no fuera suficiente)

Espero respuesta de un moderador.

[JulioC-Movistar]

Hoy ya no me da tiempo   , mañana intento replicar los tracert y ping desde un ADSL y una fibra, mañana os cuento.

[Theliel]

Buenas @velocidad

confundes lo que es una media con lo que son picos puntuales, sujetos a cualquier anormalidad de la red. Si lanzamos un ping sostenido prácticamente a cualquier host del mundo, estando en el ISP que estemos, vamos a ver lo mismo, las varianzas son normales, la latencia no es un valor absoluto ni muchísimo menos.

Para nada es un espejismo que el problema esté en Deutsche, ahí tienes los resultados en el Tracert. El tracert en Windows lanza una sucesión de 3 pruebas ICMP Echo por nodo (controlando el TTL), de ahí las 3 columnas de latencia. En los saltos de Deutche ves perfectamente que en todos los casos el salto es el que es, no hay trampa ni carton

Por otro lado en los saltos de Movistar algunos de los 3 intentos son totalmente limpios, y sólo en dos ocasiones puntuales sale una lectura alta. Según tu 30+30... estarías diciendo que absolutamente todos tus paquetes que pasan por ahí les meten la latencia alta, cuando eso no es cierto, y en tu ping sostenido lo ves. En el peor peor de los casos, el jitler alto a esos nodos es minoritario, no mayoritario, cuando el salto grande lo induce Deutche claramente.

Otra prueba de ello?? Lo tienes de nuevo en tus resultados. Mira el ping sostenido que haces de 100, y mira abajo del todo los datos finales: Latencia media = 3ms, 10 veces menos de esos 30ms que alegas.

Estoy convencido que te van a revisar la línea, que para eso está (y para otras muchas cosas) los técnicos, pero de ya te digo de antemano con total seguridad que tu línea está bien (y la de Movistar, al menos claro está en lo que a estos saltos se refiere)

Un saludo compañero.

[velocidad]

@JulioC-Movistar Gracias Julio, espero tu respuesta, aunque si con la fibra no miras sobre las horas que he dicho, no vas a ver mucho.

@ThelielCon mi antigua ADSL, haciendo ping o tracert a cualquier servidor del mundo, la diferencia entre el valor más bajo y el mas alto NUNCA superó los 10/15ms, aqui no hablamos de 10 o 15ms más sino de 110ms más, hablamos de porcentajes muy altos (más del 200%) para ser una sobrecarga puntual de un nodo, y además son más o menos sostenidos a esas horas.

En este caso se ve claramente un problema de red, y si este solo ocurre a ciertas horas, y solo ocurre con la fibra, saca las conclusiones que quieras, pero un problema hay.

Y a la red Alemana no parece que le pase nada, ellos tienen 8ms de ping con ese servidor, la pregunta es ¿que hace un paquete que sale de Madrid, y va a Alemania, para luego acabar en Inglaterra?

Como puse en mi primer post, a mi linea no le pasa nada (no así a la traza hacía ese servidor), solo tienes que ver los 1000 ping que he mandado a Sony.JP, mira la diferencia entre el más bajo y el más alto.

Saludos.

[Theliel]

Buenas @velocidad

Donde dice que tienes tienen una latencia de 8ms?? ellos no tienen una latencia de 8ms con ese servidor, resta la latencia de uno a otro. de 37 pasa a 75 y eso sin contar con la latencia que mete el propio salto 8, que restando serían otros 37-5, un total de 70ms tarda los paquetes desde Deutchs hasta el servidor de destino. Las conclusiones las saco según los datos precisamente que aportas!! Haces un tracert al servidor X, se ve la latencia a cada nodo, por otro lado puedes si quieres enviar un ping sostenido a dichos nodos y calcular la latencia media a ellos... y cuando plasmas todo ello como perfectamente has hecho, los datos son muy claros:

La red de Deutch se come 70ms ella solita, mientras que tus paquetes mientras viajan en la red de movistar se llevan unos 5-6ms. No hay mucho más que sumar!! La fibra funciona prácticamente igual al cobre, no te confundas. Sí, cambia la infraestructura a nivel local, pero ya está. Una vez que la linea de cobre se incorpora al torrente principal del ISP, este circula por los mismos canales que la fibra y otras tecnologías. El cobre tiene mayor latencia, pero esta es sobre todo debida al comiendo de de todo, es decir... desde tu roseta de teléfono hasta la centralita de del ISP y en todo caso un salto más, pero ya está, el resto es todo igual.

Saturaciones por hora del dia son diarias y comunes, a mas tráfico es más probable que exista un pico en una latencia, pero eso no significa que sea lo normal. De echo te repito, tu mismo has realizado un ping sostenido de 100, y el mismo ping te resuelve la latencia media, que sigue siendo mínima. Esto es totalmente normal.

De todos modos, como te digo, espera mañana que te conteste Julio, pero me extrañaría enormemente que te dijese que hay un problema en tu línea o en algún punto del recorrido desde tu equipo hasta las fronteras de la red de Movistar. Ni en tu línea ni en la red de Movistar... al menos como digo en los segmentos analizados. El tráfico llega bien a Deutch, y en todo todo caso un problema de Peering entre Movistar y Deuchs que haga subir la latencia en el salto 8, pero nada mas, todo lo demas es Deuchs

[JulioC-Movistar]

He realizado pruebas tando desde una fibra como desde un VDSL y desde un ADSL:

Desde fibra óptica

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

 1    <1 ms    <1 ms    <1 ms  192.168.1.1

 2     2 ms     2 ms     2 ms  192.168.144.1

 3     *        *        *     Tiempo de espera agotado para esta solicitud.

 4    16 ms    18 ms    18 ms  17.red-81-46-5.customer.static.ccgg.telefonica.net [81.46.5.17]

 5    14 ms    22 ms    14 ms  213.140.50.246

 6    16 ms    51 ms    74 ms  xe1-1-6-0-grtmadpe3.net.telefonicaglobalsolutions.com [84.16.12.141]

 7    16 ms    16 ms    16 ms  te0-1-0-12-gramadix1.net.telefonicaglobalsolutions.com [213.140.43.252]

 8    17 ms    18 ms    19 ms  213.140.52.239

 9    58 ms    58 ms    58 ms  217.239.44.42

10    59 ms    59 ms    58 ms  87.190.232.66

11    58 ms    58 ms    58 ms  195.122.154.4

12    58 ms    58 ms    58 ms  159.100.232.114

Traza completa.

ping

ping 159.100.232.114 -n 100

Haciendo ping a 159.100.232.114 con 32 bytes de datos:

Respuesta desde 159.100.232.114: bytes=32 tiempo=58ms TTL=55

Respuesta desde 159.100.232.114: bytes=32 tiempo=58ms TTL=55

.

.

.

Respuesta desde 159.100.232.114: bytes=32 tiempo=58ms TTL=55

Respuesta desde 159.100.232.114: bytes=32 tiempo=58ms TTL=55

Estadísticas de ping para 159.100.232.114:

    Paquetes: enviados = 100, recibidos = 100, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 57ms, Máximo = 59ms, Media = 58ms

Desde VDSL

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

 1    <1 ms    <1 ms    <1 ms  192.168.1.1

 2    51 ms    24 ms    24 ms  192.168.144.1

 3     *        *        *     Tiempo de espera agotado para esta solicitud.

 4    53 ms     *       34 ms  142.red-80-58-88.staticip.rima-tde.net [80.58.88

.142]

 5    69 ms    32 ms     *     213.140.50.244

 6    36 ms    36 ms    36 ms  xe0-0-4-0-grtmadad1.net.telefonicaglobalsolution

s.com [176.52.251.237]

 7     *       37 ms    36 ms  te0-0-0-7-gramadix1.net.telefonicaglobalsolution

s.com [213.140.43.2]

 8    38 ms     *       39 ms  213.140.52.237

 9    77 ms    77 ms     *     217.239.44.42

10    79 ms    78 ms    80 ms  87.190.232.74

11     *       78 ms    78 ms  195.122.154.4

12    78 ms    78 ms    77 ms  159.100.232.114

Traza completa.

ping
ping 159.100.232.114 -n 100

Haciendo ping a 159.100.232.114 con 32 bytes de datos:

Respuesta desde 159.100.232.114: bytes=32 tiempo=77ms TTL=55

Respuesta desde 159.100.232.114: bytes=32 tiempo=78ms TTL=55

.

.

.

Respuesta desde 159.100.232.114: bytes=32 tiempo=78ms TTL=55

Respuesta desde 159.100.232.114: bytes=32 tiempo=78ms TTL=55

Estadísticas de ping para 159.100.232.114:

    Paquetes: enviados = 100, recibidos = 100, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 77ms, Máximo = 119ms, Media = 79ms

Desde ADSL

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

 1    <1 ms    <1 ms    <1 ms  192.168.1.1

 2    33 ms    36 ms    33 ms  192.168.144.1

 3     *        *        *     Tiempo de espera agotado para esta solicitud.

 4    49 ms    48 ms    50 ms  138.red-80-58-88.staticip.rima-tde.net [80.58.88

.138]

 5    44 ms    56 ms    44 ms  et7-0-0-400-grtbcntb1.net.telefonicaglobalsoluti

ons.com [94.142.103.185]

 6    46 ms    46 ms    46 ms  xe1-1-6-0-grtmadpe3.net.telefonicaglobalsolution

s.com [84.16.12.141]

 7    46 ms    46 ms    47 ms  213.140.49.158

 8    49 ms    46 ms    47 ms  213.140.52.237

 9    83 ms    84 ms    84 ms  217.239.44.26

10    88 ms    89 ms    88 ms  87.190.232.70

11    89 ms    89 ms    88 ms  195.122.154.3

12    87 ms    89 ms    88 ms  159.100.232.114

Traza completa.

ping

ping 159.100.232.114 -n 100

Haciendo ping a 159.100.232.114 con 32 bytes de datos:

Respuesta desde 159.100.232.114: bytes=32 tiempo=88ms TTL=55

Respuesta desde 159.100.232.114: bytes=32 tiempo=88ms TTL=55

.

.

.

Respuesta desde 159.100.232.114: bytes=32 tiempo=88ms TTL=55

Respuesta desde 159.100.232.114: bytes=32 tiempo=88ms TTL=55

Estadísticas de ping para 159.100.232.114:

    Paquetes: enviados = 100, recibidos = 100, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 87ms, Máximo = 90ms, Media = 88ms

[velocidad]

Ayer fue el primer día desde que tengo la fibra que no pasó lo de las subidas de ping por la tarde/noche. Puede que se debiera a alguna clase de mantenimiento.

Lo voy a tener en observación unos días más y te cuento.

[JulioC-Movistar]

Mantenimiento por nuestra parte no creo, por las pruebas que dabas, mas podía deberse a algún problema temporal en algún nodo aleman, lo dejo en espera hasta el lunes, nos cuentas resultados.

Una cosa más, si ves que siguen los problemas prueba en tu red pero asegurate de que tu equipo sea el único conectado a tu router, desenchufa el resto de equipos por cable y apaga el wifi del router antes de hacer las pruebas.

[Theliel]

Buenas @velocidad

Fíjate en los datos de DSL, la diferencia principal de latencia del cobre con la fibra reside precisamente en ese salto 2, que es lo esperable, es el recorrido que hace el cobre realmente hasta la central. Una vez que se incorpora el tráfico del cobre a los canales ordinarios, las consiguientes latencias son muy similares, mirando como es natural los incrementos, claro está

Me alegro que por ahoar vaya mejor. Como dice Julio, asegúrate que cuando haces las pruebas no haya otros equipos, que podrían ser la causa no del problema que exista en Deutchs, sino del Jitter

[velocidad]

Hoy la "fiesta" ha empezado a las 20h

Esto es de hace un minuto:

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 100, recibidos = 100, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 105ms, Máximo = 138ms, Media = 122ms

tracert 159.100.232.114

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms    <1 ms     1 ms  192.168.1.1
  2     3 ms     2 ms     2 ms  192.168.144.1
  3     4 ms     3 ms     4 ms  157.red-81-46-6.customer.static.ccgg.telefonica.net [81.46.6.157]
  4     6 ms     3 ms     3 ms  86.red-81-46-8.customer.static.ccgg.telefonica.net [81.46.8.86]
  5     3 ms     3 ms     3 ms  et-15-0-0-1-401-grtmadpe3.net.telefonicaglobalsolutions.com [216.184.113.108]
  6     4 ms     4 ms     3 ms  te0-1-0-12-gramadix1.net.telefonicaglobalsolutions.com [213.140.43.252]
  7     5 ms     7 ms     7 ms  213.140.52.237
  8    37 ms    37 ms    37 ms  217.239.45.198
  9   132 ms   134 ms   132 ms  193.159.226.18
 10   136 ms   137 ms   134 ms  195.122.154.4
 11   135 ms   134 ms   129 ms  159.100.232.114

Traza completa.

Y por si hubiera alguna duda, uno de los días en los que a mi familiar le pasaba esto, yo con ADSL tenía esta traza:

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms    <1 ms    <1 ms  192.168.7.1
  2    39 ms    39 ms    38 ms  143.red-80-58-67.staticip.rima-tde.net [80.58.67.143]
  3    40 ms    40 ms    39 ms  189.red-80-58-94.staticip.rima-tde.net [80.58.94.189]
  4    43 ms    43 ms    43 ms  86.red-81-46-8.customer.static.ccgg.telefonica.net [81.46.8.86]
  5    39 ms    39 ms    39 ms  et-15-0-0-0-400-grtmadpe3.net.telefonicaglobalsolutions.com [216.184.113.106]
  6    40 ms    39 ms    41 ms  xe2-1-3-0-grtmadad1.net.telefonicaglobalsolutions.com [176.52.251.214]
  7    42 ms    42 ms    41 ms  ae-3.r01.mdrdsp04.es.bb.gin.ntt.net [129.250.66.73]
  8    85 ms    84 ms    85 ms  ae-1.r02.mdrdsp04.es.bb.gin.ntt.net [129.250.2.43]
  9   100 ms   101 ms   102 ms  ae-5.r25.amstnl02.nl.bb.gin.ntt.net [129.250.2.234]
 10   102 ms   103 ms   101 ms  ae-3.r24.amstnl02.nl.bb.gin.ntt.net [129.250.4.68]
 11    95 ms    95 ms    82 ms  ae-5.r23.londen03.uk.bb.gin.ntt.net [129.250.5.197]
 12    83 ms    84 ms    84 ms  ae-2.r02.londen03.uk.bb.gin.ntt.net [129.250.5.41]
 13    82 ms    82 ms    83 ms  ae-2.r02.londen01.uk.bb.gin.ntt.net [129.250.3.1]
 14    84 ms    83 ms    84 ms  212.119.29.18
 15    82 ms    83 ms    83 ms  unknown.prolexic.com [72.52.60.202]
 16    84 ms    83 ms    83 ms  unknown.prolexic.com [72.52.60.205]
 17    80 ms    80 ms    80 ms  209.200.180.152
 18    83 ms    84 ms    83 ms  195.122.154.3
 19    87 ms    91 ms    92 ms  159.100.232.114

Traza completa.

y ping

ping 159.100.232.114 -t

Haciendo ping a 159.100.232.114 con 32 bytes de datos:
Respuesta desde 159.100.232.114: bytes=32 tiempo=83ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=89ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=83ms TTL=54
Respuesta desde 159.100.232.114: bytes=32 tiempo=85ms TTL=54

[velocidad]

Y por si hubiera alguna duda de que hay un problema, super-ping hace 1 minuto:

PD: un único equipo conectado por cable, wifi desactivado.

[velocidad]

La verdad que muy normal no parece:

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 2732, recibidos = 2732, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 40ms, Máximo = 180ms, Media = 109ms

[Theliel]

Buenas @velocidad

La imagen se bloquea por defecto, mejor servidor externo de imagenes y enlace.

Tus datos siguen siendo coincidente con todo lo de estos días. Salto 8 (Deutche) con problemas. Si coincide por horas, está claro que están teniendo problemas con congestión en horas puntas, suele ser habitual, sobre todo si tienen problema en algún otro nodo y redirigen el tráfico hacia ese en cuestión, aumentando la congestión.

La traza de DSL en cambio muestra una ruta muy diferente, si dices que es "vieja", tendría aun más sentido, porque la ruta es muy dispar, en ese caso estaba en ntt, salto 8, el mayor problema, quitando por supuesto la mayor latencia que por lo general tenía cable de cobre (lo vemos en el segundo salto)

Lo de que existe un problema es relativo, no es una latencia alarmante como para que Deutche tome cartas en el asunto, aunque sea muy molesta para jugar, pero el % de tráfico mayoritario no es ese. Dado que no es un pico exageradamente alto no creo que lo tengan como prioridad, con lo que al final sucederá lo de siempre, en este caso Deutche tardará dias o semanas en estabilizar el tráfico de su red en el mejor de los casos... es el pal nuestro de cada día, me temo

Edito: Normal en tanto que estas cosas pasan, pero que por desgracia no hay nada que puedas hacer ni tu ni Movistar en este asunto. La latencia que tienes al servidor final es totalmente real, pero ya sabemos donde se concentra, y ese punto está fuera del alcance tanto de tu parte como de la del ISP. Y ya te digo que la experiencia nos dice que para Deut... no va a ser una prioridad ni mucho menos... lo vemos a diario.

[velocidad]

Yo no veo la relatividad del problema. Es un problema más que evidente. Sobre todo teniendo en cuenta que me pasé a la fibra para tener mejor latencia y no peor que con mi ADSL.

La media de Europa con ese servidor es 18ms, el ping desde España es 30 (teniendo en cuenta que esto va desde un datacenter es normal que sea un pelin inferior a los 40ms que tengo yo cuando funciona), pero si un paquete que tiene que ir desde España a Inglaterra, lo mandan a Alemania y encima esos nodos tienen problemas dependiendo de la hora... problema existe.

En la mano de Movistar está modificar esa traza y notificar el problema del nodo al correspondiente ISP.

PD: lo de la foto lo puedes comprobar tu mismo desde aquí: http://www.super-ping.com/?ping=159.100.232.114&locale=en

[Theliel]

Buenas @velocidad

Estamos de acuerdo que para llegar a cualquier punto del mundo por lo general existe más de un camino posible, y que ya entran ahí los mil y un acuerdos y contratos y otro millón de variables que deciden que ruta usar. Actualmente la red de Telefónica usa la red de Deutche para llegar hasta allí, y no es tampoco nada raro que se envíe a Alemania, a fin de cuenta evidentemente por algún lado tiene que pasar, y si no hay una conexión directa...

Podría Telefónica cambiar las rutas para sortear la red de Deuche?? Pues hombre, técnicamente supongo que sí, pero como tú comprenderás no van a hacerlo porque Deuche tenga lo que parece un problema temporal por saturamiento, más aun cuando el problema es visible de cara a Jugar y no el tráfico normal.

De cir que cambiaste a Fibra por la latencia como he dicho antes... lo úinco que lo diferencia, y no digo que sea poco, es ese primer segmento, pero luego es todo igual, estás sujeto exactamente al mismo funcionamiento de Internet. Sí, te ahorras a lo mejor los 30-40ms del comienzo, pero ya está. Con DSL este tipo de problemas pasan exactamente igual, no cambian.

El problema es el de siempre: Jugar. Los juegos son mucho mas sensibles a la latencia, como algunas aplicaciones en tiempo real, y por eso cada X vemos problemas como el tuyo, usuarios que durante días o semanas experimentan problemas de latencia, pero como digo es totalmente normal. Si monitorizásemos absolutamente todo el tráfico que lanzamos a internet, veríamos como navegando tenemos el mismo problema cada dos por tres, lo que pasa es que no nos damos cuenta porque no somos tan sensible a ello.

Es totalmente indiferente la latencia que tengan otras partes del mundo, igual que si entra alguien y dice eso de: Pues con mi VPN se soluciona... da igual, no varía en nada el problema y la situación actual: El tráfico que circula por algunos nodos de Deuche están más saturados a día de hoy a ciertas horas. Y eso no se aplica a ti, se aplica a todos y cualquier tipo de tráfico (suponiendo que Deutche no esté priorizando tráfico y otros, que por poder siempre pueden hacerlo)

Te guste más o menos... me temo que lo único que te lo va a solucionar es esperar, y dependiendo de cual sea la causa real de dicha saturación será más o menos. Eventualmente, como pasa siempre, se solucionará porque arreglarán algún otro nodo que de problemas o ese mismo o lo que sea. Modificar rutas, aunque técnicamente posible, no es apretar un botón, la repercusión que tiene es mucho más de lo que puedas imaginar... por ejemplo, y de forma más inmediata, podrías saturar otras redes pro el mayor tráfico que le estarías acarreando. Internet, en lo que son redes grandes, es una balanza de la que hay que ir tirando de un lado un poquito, otro lado otro poquito... o de lo contrario estaríamos todos jo***** y no solo para jugar.

Paciencia compañero, entiendo el hartazgo, pero... poco o nada puede hacer el ISP, y los otros poco van a hacer de forma urgente, sobre todo porque no es un nodo roto ni nada que sea crítico, así que.. del 1 al 10 en prioridad a lo mejor tiene un 2 o un 3 como mucho.

Paciencia, y un saludo

[JulioC-Movistar]

Lo que indica @Theliel tiene toda la vigencia posible, así funcionan las redes, comparalo con las carreteras, en ciertos horarios puede ser posible que el acceso a Madrid esté saturado por unas entradas y perfecto por otras, tiene toda la pinta de ser un problema de los nodos de Deutsche Telekom, es probable que la vía de acceso al servidor que indicas pase obligatoriamente por los nodos de Deutsche.

Aun así vamos a comprobar lo que indicas, le voy a pedir a un compañero que esté de tarde que haga tracert y ping a la 159.100.232.114 en los horarios conflictivos desde un ADSL y desde la fibra para ver que ocurre.

[JulioC-Movistar]

Mi compañero hizo los ping y tracert sobre las 21:00-21:30

Desde fibra óptica

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms    <1 ms     1 ms  192.168.1.1
  2     2 ms     3 ms     2 ms  192.168.144.1
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4    16 ms    15 ms    19 ms  17.red-81-46-5.customer.static.ccgg.telefonica.net [81.46.5.17]
  5    14 ms    23 ms    16 ms  et3-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com [94.142.103.177]
  6    15 ms    15 ms    24 ms  xe2-1-8-0-grtmadno1.net.telefonicaglobalsolutions.com [176.52.251.241]
  7    15 ms    15 ms    17 ms  xe4-0-2-0-gramadix2.net.telefonicaglobalsolutions.com [213.140.36.246]
  8     *        *        *     Tiempo de espera agotado para esta solicitud.
  9    54 ms    54 ms    53 ms  217.239.44.10
 10    99 ms   100 ms    99 ms  87.190.232.66
 11   108 ms   107 ms   100 ms  195.122.154.4
 12   103 ms   106 ms   106 ms  159.100.232.114

Traza completa.

ping

ping 159.100.232.114

Haciendo ping a 159.100.232.114 con 32 bytes de datos:
Respuesta desde 159.100.232.114: bytes=32 tiempo=91ms TTL=55
Respuesta desde 159.100.232.114: bytes=32 tiempo=92ms TTL=55
Respuesta desde 159.100.232.114: bytes=32 tiempo=90ms TTL=55
Respuesta desde 159.100.232.114: bytes=32 tiempo=88ms TTL=55

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 88ms, Máximo = 92ms, Media = 90ms

Desde ADSL

Traza a 159.100.232.114 sobre caminos de 30 saltos como máximo.

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    33 ms    33 ms    34 ms  192.168.144.1
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4    49 ms    46 ms    47 ms  138.red-80-58-88.staticip.rima-tde.net [80.58.88.138]
  5    63 ms    46 ms    56 ms  et7-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com [94.142.103.185]
  6    51 ms    46 ms    45 ms  xe1-1-6-0-grtmadpe3.net.telefonicaglobalsolutions.com [84.16.12.141]
  7    46 ms    46 ms    46 ms  xe7-0-2-0-gramadix2.net.telefonicaglobalsolutions.com [84.16.13.184]
  8     *        *        *     Tiempo de espera agotado para esta solicitud.
  9    82 ms    82 ms    80 ms  217.239.44.26
 10   137 ms   142 ms   143 ms  87.190.232.70
 11   134 ms   134 ms   135 ms  195.122.154.3
 12   121 ms   121 ms   120 ms  159.100.232.114

ping

ping 159.100.232.114

ping 159.100.232.114

Haciendo ping a 159.100.232.114 con 32 bytes de datos:
Respuesta desde 159.100.232.114: bytes=32 tiempo=126ms TTL=55
Respuesta desde 159.100.232.114: bytes=32 tiempo=123ms TTL=55
Respuesta desde 159.100.232.114: bytes=32 tiempo=136ms TTL=55
Respuesta desde 159.100.232.114: bytes=32 tiempo=129ms TTL=55

Estadísticas de ping para 159.100.232.114:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 123ms, Máximo = 136ms, Media = 128ms

[JulioC-Movistar]

Como puedes ver si que aumentan los tiempos, pero no en nuestra red, es probable que sean saturaciones temporales en los nodos de deutsche telekom, también puedes observar que la diferencia entre el adsl y la fibra son unos 30-40 ms a favor de la fibra, la ruta es la misma y los retardos también. Lo siento pero no es algo escandaloso como para poder mover a DTelekom a hacer algo, probablemente tengan alarmas de saturación e iran tomando medidas para corregirlas.

[velocidad]

Debe ser entonces que al yo tener IP fija cuando tenía el ADSL cambiaban las rutas, los ping y tracert que he puesto no me los he inventado, solo son copiar/pegar.

En cualquier caso, y aunque sean problemas temporales (posiblemente por saturación), ¿sería posible que pasaras este tema a infraestructuras, a ver si ellos pueden ponerse en contacto con Deutche Telkom o cambiar la ruta? Es que es muy molesto, tener (en algunos casos) hasta 100ms más de ping que cualquier compañero europeo y eso que ellos no tienen fibra óptica.

Y saliendo del tema, tenía este tema abierto y estaba esperando una respuesta. Me han cerrado el tema aunque no tiene nada que ver con este porque me estabas atendiendo en este hilo, pero aún así me gustaría obtener una respuesta.

http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/192-168-144-1-y-como-salir...

[Theliel]

Buenas @velocidad

Las rutas pueden variar, no son para nada absolutas, pero ya sea DSL o fibra. Estoy seguro que no inventas nada compañero. Pero en cualquier caso es lo mismo, tanto en tus trazas como en las de todos nosotros los resultados son totalmente concluyente y apuntan exactamete a lo mismo.

Lo otro te lo ha contestado Julio, no es nada alarmante como para contactar con Deutch, que sea muy molesto para jugar estoy totalmente de acuerdo contigo, pero para más del 90% del tráfico no es para nada algo que se note. A medio largo plazo se solucionará solo

Y sobre la puerta de enlace de la conexión PPPoE... creo recordar que lo aclaramos al final, no??

Un saludo compi, y paciencia, que los problemas de latencias de este tipo suelen solucoinarse al final, aunque son muy molestos

[JulioC-Movistar]

El salto por la 192.168.144.1 es un salto normal (la OLT), no es un MITM. No se da en todas las fibras porque no todas tienen la misma OLT (fabricante) ni configuración, pero tiene que estar ahí no le des más vueltas.

En cuanto a abrir avería..... con esa latencia lo dan por bueno, no se escala el problema a DT, como has podido comprobar es algo variable

".....Ayer fue el primer día desde que tengo la fibra que no pasó lo de las subidas de ping por la tarde/noche. Puede que se debiera a alguna clase de mantenimiento...."

Y fuera de nuestra red.... lo siento pero no veo el motivo para abrir una avería, si insistes la abro pero ya te anticipo la contestación de infraestructuras por todas las experiencias anteriores.

[velocidad]

Gracias por las respuestas.

Abrir avería no, yo solo decía pasar este reporte a infraestructuras aunque si dices que en otras ocasiones no han hecho nada...

De todos modos, si esto se alarga en el tiempo, ¿que recomendación me dais?

[Theliel]

Buenas @velocidad

Bufff, recomendación no hay, me temo. Podrías dirigirte directamente a Deuchs, pero no te van a hacer ningún caso, honestamente hablando.

Tal como dice Julio, es de presuponer que ellos mismos tienen monitorizada toda su red y alarmas e indicativos sobre cualquier congestión o punto negro, sería un poco tonto pensar que ellos no son consciente de ello. La experiencia dice que se termina resolviendo, pero... a lo mejor tienen problemas en otro nodo y tienen que redirigir por otra parte el tráfico y se satura más, o puden tener un problema específico en ese, o por el motivo que sea están experimentando un incremento de tráfico por ese lado y están viendo si se normaliza... opciones miles, pero por desgracia desde tu lado, poco vas a poder hacer, me temo.

Y no... no hay trucos que puedan hacerse para mejorarlo a nivel de Router o a nivel de equipo. Si fuese un valor muy alarmante, todabía, pero a esos valores nadie va a darle urgencia. Lo siento compi 😞