Buenas, tengo fibra de Movistar con 300mb simétricos y en videojuegos como CounterStrike o Rust hay microcortes que imposibilitan jugar. Los fps son estables. Amigos que tienen el mismo juego y jugamos en los mismo servidores no tienen ese mismo problema al no ser de Movistar. He reiniciado en varias ocasiones el router y no se soluciona, llevo 3-4 dias así.
Una solución ya por favor.
Buenas @RustPlayer
Por desgracia con esos datos poco podemos ayudarte. Lo primero que hay que saber es si usas Cable o WIFI, y lo segundo ver algún tracert hacia algún servidor que uses.
Sobre WIFI/cable, es esencial, si es por WIFI automáticamente te digo que problema cazado, usa cable. Las conexiones WIFI son extremadamente variables no solo a tu propio tráfico dentro de la red, sino a interferencias, incluso simplemente porque tengas un sólo dispositivo conectado a WIFI, es suficiente. Digamos que jugar y WIFI, no debería de usarse en la misma frase. Eso no quiere decir que no se pueda, claro que se puede, y mucha veces puede ir perfecto. Pero la cantidad de factores que pueden producir que aparezca el problema, son tantos que nos podríamos llevar todo el día con ello.
Si es cable, hay que ver mas cosas, empezando por un tracert. El tracert nos diría donde existe la pérdida de latencia mayor, si en tu propia red interna, en la red de Movistar, en la red de un tercero o incluso en la red de los servidores finales.
Uso siempre cable. Si me explicas como hacer lo de tracert lo hago
Es sencillo compañero
Busca una IP a la que te conectes, sea cual sea el juego no debería de ser complicado encontrarla. La ip tiene el formato xxx.xxx.xxx.xxx por si nunca has visto una.
Acto seguido solo tienes que ir a cualquier equipo, por ejemplo en Windows, salir a la consola de windows con CMD, y escribir:
tracert IP
tardará un ratito, empezarán a salir paquetes y latencias en cada salto. Cuando termine, copias pegas y listo
C:\Users\Carlos>tracert 31.186.251.76
Traza a la dirección d-31-186-251-76.ded-machine.internap-frankfurt.nfoservers.com [31.186.251.76]
sobre un máximo de 30 saltos:
1 <1 ms <1 ms 4 ms 192.168.1.1
2 2 ms 2 ms 2 ms 169.red-80-58-67.staticip.rima-tde.net [80.58.67.169]
3 * * * Tiempo de espera agotado para esta solicitud.
4 23 ms 19 ms 20 ms 17.red-81-46-5.customer.static.ccgg.telefonica.net [81.46.5.17]
5 19 ms 23 ms 19 ms et3-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com [94.142.103.177]
6 55 ms 55 ms 55 ms 94.142.117.69
7 53 ms 52 ms 52 ms be12956.rcr21.b023101-0.lon01.atlas.cogentco.com [130.117.15.157]
8 53 ms 57 ms 64 ms be2950.ccr22.lon01.atlas.cogentco.com [130.117.2.109]
9 53 ms 53 ms 53 ms be2869.ccr42.lon13.atlas.cogentco.com [154.54.57.161]
10 57 ms 56 ms 56 ms be12488.ccr42.ams03.atlas.cogentco.com [130.117.51.42]
11 60 ms 61 ms 61 ms be2814.ccr42.fra03.atlas.cogentco.com [130.117.0.142]
12 65 ms 65 ms 65 ms be2502.rcr21.b015749-1.fra03.atlas.cogentco.com [154.54.39.182]
13 61 ms 61 ms 61 ms 149.11.106.34
14 66 ms 66 ms 66 ms border4.ae1-bbnet1.fra002.pnap.net [95.172.67.8]
15 64 ms 64 ms 64 ms d-31-186-251-76.ded-machine.internap-frankfurt.nfoservers.com [31.186.251.76]
Traza completa.
C:\Users\Carlos>
Dan micro subidas de ping de vez en cuando, aunque ahora parece que se mantiene estable
Buenas @RustPlayer
La aportación de latencia mas grande aparece en el salto 6, pertenece a Movistar, pero podría ser por la hora. Aun así una latencia final de unos 64 es normal, está dentro de lo más que aceptable. Si tienes picos, usa mejor WinMTR
http://winmtr.net/download-winmtr/
Te permite envíar una salva sostenida, que es mucho más fiable para detectar picos o subidas/bajadas. Envía unos 500-1000 paquetes y lo paras, a ver que da
Ahora mismo no tengo ningun tipo de pico, hace un par de horas picos cada 15-20 segundos de 600 de ping como mínimo
ok, lánzalo cuando veas q la cosa va mal, y podemos ver con un poco de suerte donde se acumula.
Vuelta al lag
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 300 | 300 | 0 | 0 | 2 | 0 |
| 169.red-80-58-67.staticip.rima-tde.net - 0 | 300 | 300 | 1 | 2 | 22 | 2 |
| No response from host - 100 | 61 | 0 | 0 | 0 | 0 | 0 |
| 194.red-80-58-77.staticip.rima-tde.net - 0 | 300 | 300 | 16 | 19 | 40 | 18 |
|et6-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com - 0 | 300 | 300 | 15 | 20 | 90 | 16 |
| 176.52.250.242 - 0 | 300 | 300 | 47 | 49 | 53 | 50 |
|be12956.rcr21.b023101-0.lon01.atlas.cogentco.com - 0 | 300 | 300 | 47 | 48 | 51 | 48 |
| be2950.ccr22.lon01.atlas.cogentco.com - 0 | 300 | 300 | 47 | 48 | 53 | 49 |
| be2869.ccr42.lon13.atlas.cogentco.com - 0 | 300 | 300 | 48 | 48 | 51 | 49 |
| be12488.ccr42.ams03.atlas.cogentco.com - 0 | 300 | 300 | 55 | 56 | 59 | 57 |
| be2814.ccr42.fra03.atlas.cogentco.com - 0 | 300 | 300 | 55 | 55 | 59 | 56 |
|be2502.rcr21.b015749-1.fra03.atlas.cogentco.com - 0 | 300 | 300 | 57 | 57 | 60 | 59 |
| 149.11.106.22 - 2 | 284 | 279 | 0 | 57 | 81 | 69 |
| border3.ae1-bbnet1.fra002.pnap.net - 2 | 284 | 279 | 55 | 57 | 78 | 67 |
|d-31-186-251-76.ded-machine.internap-frankfurt.nfoservers.com - 2 | 281 | 276 | 61 | 63 | 84 | 68 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Este problema le sucede únicamente a gente de Movistar, estoy muy indignado por esto.
Editado 25-09-2017 23:28
Editado 25-09-2017 23:28
Buenas @RustPlayer
la aportación mas alta en todo caso es en el salto 6, que sigue estando en el lado de Movistar y podrían echarle un ojo, quizás saturación por horas. Pero de todos modos la latencia final son 63 de media, que está de sobras dentro de los parámetros normales. He visto tu vídeo y te aseguro que eso no son 63 segundos, ni parece un lag debido a latencia. Hay a veces pausas de incluso medio segundos y desincronización, y eso me huele mas a pérdida de paquetes.
En el salto 13 más o menos, si miras WinMTR, los 300 paquetes enviados y recibidos que hasta el momento son 300/300 hay un pequeño % de estos que se pierde, según la estadística un 2% más o menos. Normalmente un tracert/ping no puede indicarnos pérdidas de paquetes, o al menos hay que mirarlo con lupa, pero en este caso el comportamiento se arrastra desde el salto 13 hasta el final, todo en la red de Cogent.
En lo personal, al margen de que la latencia en el salto 6 sea mejorable, no es eso lo que te pasa. En tu vídeo no hay un problema de latencia, tienes "saltos" de más de medio segundo a veces, no es el salto 6. Así que o es un fallo de los propios servidores y un problema de sincronía, o en cogent tienen un problema con pérdida de paquetes. Un 2% no es mucho, pero si tenemos en cuenta que la tasa normal de pérdida de una conexión ronda los 0.5%, y en un juego, pues podría ser tu problema.
Y sí, son problemas que pasan con todos los ISP, aun cuando fuese un problema específico de un nodo de Movistar
Picos de ping altos, en el juego llega a marcar 2500 de ping
Traza a la dirección d-31-186-251-11.ded-machine.internap-frankfurt.nfoservers.com [31.186.251.11]
sobre un máximo de 30 saltos:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 2 ms 3 ms 2 ms 169.red-80-58-67.staticip.rima-tde.net [80.58.67.169]
3 * * * Tiempo de espera agotado para esta solicitud.
4 16 ms 18 ms 16 ms 21.red-80-58-84.staticip.rima-tde.net [80.58.84.21]
5 16 ms 19 ms 19 ms 113.red-81-46-1.customer.static.ccgg.telefonica.net [81.46.1.113]
6 16 ms 22 ms 22 ms et7-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com [94.142.103.185]
7 * * * Tiempo de espera agotado para esta solicitud.
8 87 ms 93 ms 88 ms be12956.rcr21.b023101-0.lon01.atlas.cogentco.com [130.117.15.157]
9 51 ms 51 ms 51 ms be2950.ccr22.lon01.atlas.cogentco.com [130.117.2.109]
10 51 ms 51 ms 51 ms be2869.ccr42.lon13.atlas.cogentco.com [154.54.57.161]
11 58 ms 58 ms 57 ms be12488.ccr42.ams03.atlas.cogentco.com [130.117.51.42]
12 61 ms 61 ms 62 ms be2814.ccr42.fra03.atlas.cogentco.com [130.117.0.142]
13 63 ms 62 ms 63 ms be2502.rcr21.b015749-1.fra03.atlas.cogentco.com [154.54.39.182]
14 63 ms 63 ms 63 ms 149.11.106.30
15 95 ms 99 ms 100 ms border3.ae2-bbnet2.fra002.pnap.net [95.172.67.71]
16 61 ms 62 ms 62 ms d-31-186-251-11.ded-machine.internap-frankfurt.nfoservers.com [31.186.251.11]
Traza completa.
Buenas @RustPlayer
Ese tracert es correcto y no evidencia nada raro.
En el salto 8 (perteneciente a cogentco) hay una subida importante, pero no es coherente con el resto de saltos con lo que debe de filtrar ligeramente el tráfico icmp, algo similar que ocurre ene l salto 15, perteneciente a pnap.
La latencia final es de 62ms, que está dentro de lo más que normal.
Para descartar picos que puedan aparecer puntualmente y eliminar el factor estadístico, usa WinMTR:
http://winmtr.net/download-winmtr/
Y lanza una salva por ejemplo de 500-1000 paquetes, y pones el resultado, por si se puede ver algo que sea más extraño, en el tracert que pones, no hay nada de nada.
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 469 | 469 | 0 | 0 | 3 | 0 |
| 169.red-80-58-67.staticip.rima-tde.net - 0 | 469 | 469 | 1 | 2 | 25 | 2 |
| No response from host - 100 | 93 | 0 | 0 | 0 | 0 | 0 |
| 21.red-80-58-84.staticip.rima-tde.net - 0 | 469 | 469 | 15 | 17 | 121 | 16 |
|113.red-81-46-1.customer.static.ccgg.telefonica.net - 0 | 469 | 469 | 16 | 17 | 40 | 18 |
|et7-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com - 0 | 469 | 469 | 15 | 18 | 97 | 16 |
| No response from host - 100 | 93 | 0 | 0 | 0 | 0 | 0 |
|be12956.rcr21.b023101-0.lon01.atlas.cogentco.com - 5 | 402 | 385 | 86 | 89 | 106 | 88 |
| be2950.ccr22.lon01.atlas.cogentco.com - 0 | 469 | 469 | 49 | 50 | 56 | 51 |
| be2869.ccr42.lon13.atlas.cogentco.com - 0 | 469 | 469 | 49 | 49 | 62 | 50 |
| be12488.ccr42.ams03.atlas.cogentco.com - 0 | 469 | 469 | 56 | 57 | 65 | 58 |
| be2814.ccr42.fra03.atlas.cogentco.com - 1 | 465 | 464 | 60 | 61 | 71 | 61 |
|be2502.rcr21.b015749-1.fra03.atlas.cogentco.com - 0 | 469 | 469 | 61 | 62 | 76 | 62 |
| 149.11.106.30 - 0 | 469 | 469 | 53 | 58 | 69 | 57 |
| border3.ae2-bbnet2.fra002.pnap.net - 2 | 449 | 444 | 56 | 65 | 105 | 57 |
|d-31-186-251-11.ded-machine.internap-frankfurt.nfoservers.com - 1 | 462 | 460 | 56 | 61 | 68 | 63 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Buenas @RustPlayer
Gracias por el paste.
No hay nada raro, al menos a esa hora, a ese servidor.
Los datos del servidor final son buenos, prácticamente no hay siquiera jitter (diferencia media las latencias altas/bajas). Un mínimo de 56, máximo de 68 y media de 61, son valores muy planos, el jitter sería despreciable, ya no es que exista latencia, es que tampoco hay picos. De ahí la importancia de mandar una salva grande, porque un tracert normal manda 3 paquetes, y en un momento dado imagina que en ese instante la red cambia para bien o mal. Con 500 paquetes los datos son más fidedignos.
Tampoco veo pérdida de paquetes observables, al destino final aparece un 1%, pero precedido por un 2% en el salto anterior y un 0 en el anterior.
Los saltos que sí muestran disparidad, como el salto 3, el 4, 6 y algún otro, donde se aprecian máximos elevados, son despreciables si tenemos en cuenta que la evolución de los nodos lo normaliza, con lo sencillamente algunos nodos priorizan/filtran un poco de tráfico ICMP, nada que afecte a tráfico real.
Te recomendaría que repitas cuando te esté sucediendo, porque al menos en el momento que lo realizaste, el estado de la red desde tu equipo hasta el servidor final es bastante buena.Si aun así experimentabas dichos problemas, el causante es o un fallo de sincronización entre el cliente<->servidor (el juego en el equipo porque han metido la pata en alguna actualización o el servidor remoto), o cualquier otro problema en tu equipo que afecta realmente sólo a lo que realmente ves, como Drivers de Vídeos o cualquier cosa similar.