El tracert lo que intenta es analizar la ruta que toma, los saltos o nodos por los que va pasando, en el ejemplo creado pasa por cuatro nodos antes de llegar al servidor. Para analizar que equipos o nodos atraviesa les manda un ping y comprueba en que tiempo responde, lo normal es que según te vas alejando del origen el ping se vaya incrementando por el incremento de la distancia a recorrer.
Desde un router se lanza un tracert a un servidor X (5)
Tracert a un servidor X
1 5 ms 5 ms 5ms 80.23.5.13
2 3 ms 7ms 6 ms 104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
3 * * * Tiempo de espera agotado para esta solicitud.
4 1357 ms 77 ms 25 ms 5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
5 25 ms 36 ms 25 ms servidor X [217.53.125.5]
Traza completa.
En este ejemplo se pueden ver varios casos:
1 5 ms 5 ms 5ms 80.23.5.13
2 3 ms 7ms 6 ms 104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
El tiempo del salto al nodo 2 es menor que el tiempo de salto al nodo 1, algo a priori no posible ya que la distancia es mayor y si hasta el nodo 1 hay un retardo de 5 ms al nodo 2 debiera tener un retardo de 5 ms + XXX ya que está más lejos, la explicación es que el nodo 1 ha tardado en responder algo más de lo habitual por cualquier motivo, no es síntoma de nada en concreto.
3 * * * Tiempo de espera agotado para esta solicitud.
Puede pasar que como ocurre en el salto 3 que el nodo correspondiente no responda a las peticiones de ping (es lo que hace el tracert, pedir un ping a cada nodo), esta ausencia de respuesta puede ser algo totalmente voluntario por parte del nodo -está configurado para no responder a ningún ping- o algo que dependa de la política de respuesta configurada en ese nodo -puede ser que solo responda 5 peticiones por segundo y las demás las descarte-. Es algo normal y habitual, no es síntoma de nada erróneo, NO son paquetes perdidos, son paquetes que el nodo no contesta, paquetes que desecha.
El trabajo del nodo es trasladar al siguiente nodo los paquetes de transito que le llegan, este trabajo lo sigue haciendo sin ningún problema aunque no conteste al ping ya que vemos que la traza llega al siguiente nodo 4 y progresa hasta su destino al servidor X, esto no ocurriría si se perdiese el paquete.
4 1357 ms 77 ms 25 ms 5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
5 25 ms 36 ms 25 ms servidor X [217.53.125.5]
Puede pasar también lo que ocurre en el salto 4, un incremento brutal del ping (1357 ms), la explicación es la misma que en el caso de los saltos 1 y 2, el nodo 4 está ocupado haciendo otras tareas -reencaminar los paquetes que le llegan hacia su destino final- y tarda mucho en responder a peticiones no prioritarias como un ping, no es sintoma de nada en concreto, puede ser que tarde en responder por carga de trabajo o simplemente por la política de respuesta a ping que tiene configurada el nodo. Si este nodo introdujese un retardo de 1357 ms el siguiente estaría respondiendo con un ping de 1357 ms + XXX y en cambio lo hace con un valor normal de 25 ms.
En definitiva lo único que importa es la respuesta al ping final, la respuesta de los nodos intermedios hay que descartarla por sistema. Podéis comprobar que está misma explicación la dan desarrolladores de softwares conocidos y ampliamente usados como por ejemplo PingPlotter http://www.pingman.com/kb/24
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
JulioC-Movistar escribió:El tracert lo que intenta es analizar la ruta que toma, los saltos o nodos por los que va pasando, en el ejemplo creado pasa por cuatro nodos antes de llegar al servidor. Para analizar que equipos o nodos atraviesa les manda un ping y comprueba en que tiempo responde, lo normal es que según te vas alejando del origen el ping se vaya incrementando por el incremento de la distancia a recorrer.
Desde un router se lanza un tracert a un servidor X (5)
Tracert a un servidor X
1 5 ms 5 ms 5ms 80.23.5.13
2 3 ms 7ms 6 ms 104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
3 * * * Tiempo de espera agotado para esta solicitud.
4 1357 ms 77 ms 25 ms 5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
5 25 ms 36 ms 25 ms servidor X [217.53.125.5]
Traza completa.
En este ejemplo se pueden ver varios casos:
1 5 ms 5 ms 5ms 80.23.5.13
2 3 ms 7ms 6 ms 104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
El tiempo del salto al nodo 2 es menor que el tiempo de salto al nodo 1, algo a priori no posible ya que la distancia es mayor y si hasta el nodo 1 hay un retardo de 5 ms al nodo 2 debiera tener un retardo de 5 ms + XXX ya que está más lejos, la explicación es que el nodo 1 ha tardado en responder algo más de lo habitual por cualquier motivo, no es síntoma de nada en concreto.
3 * * * Tiempo de espera agotado para esta solicitud.
Puede pasar que como ocurre en el salto 3 que el nodo correspondiente no responda a las peticiones de ping (es lo que hace el tracert, pedir un ping a cada nodo), esta ausencia de respuesta puede ser algo totalmente voluntario por parte del nodo -está configurado para no responder a ningún ping- o algo que dependa de la política de respuesta configurada en ese nodo -puede ser que solo responda 5 peticiones por segundo y las demás las descarte-. Es algo normal y habitual, no es síntoma de nada erróneo, NO son paquetes perdidos, son paquetes que el nodo no contesta, paquetes que desecha.
El trabajo del nodo es trasladar al siguiente nodo los paquetes de transito que le llegan, este trabajo lo sigue haciendo sin ningún problema aunque no conteste al ping ya que vemos que la traza llega al siguiente nodo 4 y progresa hasta su destino al servidor X, esto no ocurriría si se perdiese el paquete.
4 1357 ms 77 ms 25 ms 5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
5 25 ms 36 ms 25 ms servidor X [217.53.125.5]
Puede pasar también lo que ocurre en el salto 4, un incremento brutal del ping (1357 ms), la explicación es la misma que en el caso de los saltos 1 y 2, el nodo 4 está ocupado haciendo otras tareas -reencaminar los paquetes que le llegan hacia su destino final- y tarda mucho en responder a peticiones no prioritarias como un ping, no es sintoma de nada en concreto, puede ser que tarde en responder por carga de trabajo o simplemente por la política de respuesta a ping que tiene configurada el nodo. Si este nodo introdujese un retardo de 1357 ms el siguiente estaría respondiendo con un ping de 1357 ms + XXX y en cambio lo hace con un valor normal de 25 ms.
En definitiva lo único que importa es la respuesta al ping final, la respuesta de los nodos intermedios hay que descartarla por sistema. Podéis comprobar que está misma explicación la dan desarrolladores de softwares conocidos y ampliamente usados como por ejemplo PingPlotter http://www.pingman.com/kb/24
Entiendo lo que comentas,pero no te parece exagerado que en el nodo 7
7 1357 ms 678 ms 340 ms 5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
como ultimo ping a un servidor de francia sea de 340 de ping
ahora te voi a poner otro tracert,que por lo visto a mejorado,y te pregunto si la ruta final de la conexion es en estados unidos,para que primero va a francia y luego a estados unidos? no es mas rapido ir de madrid a estados unidos directamente.
esta traza esta hecha hoy dia 31/10/2016 a las 14:50
Traza a la dirección twitch.tv [52.41.96.17] sobre un máximo de 30 saltos: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 2 ms 1 ms 1 ms 104.red-80-58-67.staticip.rima-tde.net [80.58.67 .104] 3 * * * Tiempo de espera agotado para esta solicitud. 4 52 ms 25 ms 25 ms 198.red-80-58-83.staticip.rima-tde.net [80.58.83 .198] 5 24 ms 24 ms 24 ms 213.140.51.13 6 91 ms 162 ms 47 ms xe5-0-4-0-grtparix3.net.telefonicaglobalsolution s.com [213.140.33.91] 7 * 49 ms 52 ms 5-2-17.ear2.Paris1.Level3.net [212.73.207.45] 8 203 ms 203 ms 203 ms ae-2-52.ear2.Seattle1.Level3.net [4.69.206.65] 9 206 ms 206 ms 206 ms 4.16.146.90 10 217 ms 314 ms 221 ms 52.95.54.80 11 211 ms 211 ms 211 ms 52.95.54.95 12 215 ms 215 ms 215 ms 54.239.43.9 13 253 ms 216 ms 215 ms 52.93.14.220 14 214 ms 214 ms 214 ms 52.93.14.217 15 * * * Tiempo de espera agotado para esta solicitud. 16 * * * Tiempo de espera agotado para esta solicitud. 17 214 ms 214 ms 214 ms 205.251.232.225 18 * * * Tiempo de espera agotado para esta solicitud. 19 * * * Tiempo de espera agotado para esta solicitud. 20 * * * Tiempo de espera agotado para esta solicitud. 21 * * * Tiempo de espera agotado para esta solicitud. 22 * * * Tiempo de espera agotado para esta solicitud. 23 * * * Tiempo de espera agotado para esta solicitud. 24 * * * Tiempo de espera agotado para esta solicitud. 25 * * * Tiempo de espera agotado para esta solicitud. 26 * * * Tiempo de espera agotado para esta solicitud. 27 * * * Tiempo de espera agotado para esta solicitud. 28 * * * Tiempo de espera agotado para esta solicitud. 29 * * * Tiempo de espera agotado para esta solicitud. 30 * * * Tiempo de espera agotado para esta solicitud. Traza completa.
como ves primero va a madrid,luego va en el nodo 7 va a paris.leve13.net para de hay ir a el nodo 8 a seattle1.leve13.net
un tracert directamente a seattle1.leve13.net:
Traza a la dirección ae-2-52.ear2.Seattle1.Level3.net [4.69.206.65] sobre un máximo de 30 saltos: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 2 ms 1 ms 1 ms 104.red-80-58-67.staticip.rima-tde.net [80.58.67 .104] 3 * * * Tiempo de espera agotado para esta solicitud. 4 27 ms 27 ms 25 ms 225.red-80-58-106.staticip.rima-tde.net [80.58.1 06.225] 5 24 ms 24 ms 24 ms ae1-400-gramadte2.net.telefonicaglobalsolutions. com [216.184.113.186] 6 25 ms 24 ms 24 ms lag-13.ear1.Madrid2.Level3.net [4.68.111.33] 7 25 ms 24 ms 24 ms vl-3103-ve-131.ebr1.Madrid2.Level3.net [4.69.210 .69] 8 49 ms 43 ms 42 ms ae-45-45.ebr2.Paris1.Level3.net [4.69.158.34] 9 147 ms 146 ms 160 ms ae-40-40.ebr4.Washington1.Level3.net [4.69.137.1 74] 10 146 ms 147 ms 146 ms ae-1-11.ebr3.Washington1.Level3.net [4.69.204.25 3] 11 166 ms 149 ms 149 ms ae-15-3615.ebr4.Atlanta2.Level3.net [4.69.150.23 3] 12 * 157 ms 157 ms ae-41-41.ebr5.Dallas1.Level3.net [4.69.209.238] 13 178 ms 178 ms 184 ms ae-28-28.ebr3.Denver1.Level3.net [4.69.210.189] 14 174 ms 174 ms 174 ms ae-1-11.ebr4.Denver1.Level3.net [4.69.206.214] 15 199 ms 210 ms 199 ms ae-3.ebr4.Seattle1.Level3.net [4.69.203.237] 16 199 ms 199 ms 201 ms ae-2-52.ear2.Seattle1.Level3.net [4.69.206.65] Traza completa.
en mi opinion aqui el nodo que sobra es el 8,que va de madrid a paris,cuando deberia de ir directamente desde madrid al servidor de estados unidos,al nodo 9 Washington1.Level3.net
El tiempo de respuesta de los nodos intermedios como te decía no es significativo de nada, simplemente ese nodo no prioriza la respuesta al ping, es más con un poco más de tiempo daría como no contestado y de forma errónea se podría interpretar como paquete perdido cuando no es así.
Por otro lado para llegar a un determinado servidor lo tenemos que hacer por las rutas por las que se anuncia ese servidor, probablemente solo se anuncia por la ruta a la que tenemos acceso por Paris.
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
@romanalvarado ¿Has probado a cambiar los servidores a los que emites? ¿En todos tienes la misma limitación?
@spawn El problema que planteas, un usuario movistar emite y el resto de usuarios movistar lo ve con parones de buffer ya se planteó hace tiempo y el problema está en que no podemos probarlo ya que entra en medio la red de twitch, lo que tu emites llega bien a twitch, si un usuario de otra operadora lo quiere ver lo ve sin problemas, los usuarios de Movistar que ven tu stream con buffering ven otros videos -de usuarios de otras operadoras- sin buffer. No es algo que solo le ocurra a Movistar Can't watch my own stream while streaming from the same internet connection (EEUU) , ya se trató en su día sin solución explicacion de funcionamiento de twitch
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
El Gif que ves lo hice en su día por una queja similar, en aquel momento veiamos que la descarga la hacía desde un cdn en Amsterdan si no recuerdo mal, el envío se realizaba a EEUU, lo que hace twitch entre medias lo desconozco, puedes ver desde donde descargas el video siguiendo estas instrucciones
Hay que analizar las conexiones, os tenéis que bajar el TCPview de Microsoft, es un fichero zip
descomprimis el zip en una carpeta donde os encontraréis estos archivos
Con el botón derecho del ratón hacemos clic encima de Tcpview.exe y lo ejecutamos como administrador.
Ahora arrancamos un navegador y nos vamos a twitch.tv y visualizamos un directo cualquiera
En el TCPView clicamos en la columna Rcvd Bytes (Bytes recibidos) para ordenarlo de mayor a menor
esperamos 2-3 minutos y comprobamos cual es la IP que tiene más Bytes recibidos, esa será la IP del CDN de video de twitch desde el que os está sirviendo datos de video, esa es la IP que nos hace falta saber, por favor enviarme un privado con ese dato, vuestra IP en ese momento y un tracert a esa IP (dejar que acabe el tracert, que de traza completa, le lleva un rato) todos estos datos en modo texto por favor.
Luego puedes ver la localización de esa IP en ipinfo.io
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
No hemos tenido más noticias tuyas, espero que tu duda haya quedado resuelta, si para mañana no hemos recibido noticia en contra lo daremos por solucionado y cerraremos el hilo, si te encuentras el hilo cerrado y sigues con problemas no dudes en ponerte en contacto de nuevo con nosotros en Soporte Técnico Banda Ancha
Si consideras que alguna de las respuestas es la solución a tu duda o problema, te agradecería que la marques clicando en el botón "Aceptar como solución" con esa acción ayudarás a otros usuarios que puedan tener el mismo problema.
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
