Lag en juegos, teletrabajo, etc
Buenas tardes. Desde aproximadamente junio de 2024 vengo sufriendo retrasos en la conexión cuando estoy conectado al router de fibra, tanto por cable como por wifi. Me sucede en juegos online, en la...
Foro
Hola printertale
Hemos verificado los reportes anteriores que has realizado, los técnicos indican que el servicio se encuentra funcionando correctamente.
Seria que intentaras conectando otros dispositivos y, si teletrabajas puede que tengas una vpn en el ordenador, la cual seria recomendable desconectar para jugar dado que puede generar cortes en la conexión.
Quedamos atentos a tus comentarios.
Un saludo.
Dayana.
Buenas tardes.
El problema no se ha solucionado, persiste de la misma manera desde agosto que abrí la primera incidencia al 1002.
Se refiere a haber examinado los reportes anteriores que adjunté en este hilo? ¿Esa es la revisión exhaustiva de mi línea?
El VPN para conectarme al trabajo está en otro equipo diferente al equipo donde me ocurren los cortes en los juegos. Fallan ambos, por separado e incluso conectados a la vez.
He realizado otras pruebas, porque en los servidores de juegos no siempre hay un único servidor de destino, así que aquí van los nuevos resultados.
Juego 1
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 1209 | 1209 | 0 | 0 | 7 | 0 |
| 192.168.144.1 - 1 | 1202 | 1200 | 1 | 1 | 19 | 2 |
|125.red-81-46-65.customer.static.ccgg.telefonica.net - 99 | 248 | 4 | 2 | 4 | 11 | 2 |
|18.red-81-46-66.customer.static.ccgg.telefonica.net - 29 | 575 | 413 | 2 | 3 | 22 | 3 |
|205.red-81-46-0.customer.static.ccgg.telefonica.net - 0 | 1209 | 1209 | 2 | 3 | 23 | 2 |
|gramadix2-ae10.net.telefonicaglobalsolutions.com - 68 | 331 | 107 | 2 | 3 | 15 | 3 |
| 176.52.248.250 - 2 | 1150 | 1134 | 2 | 3 | 28 | 3 |
|microsoft-be18-grtmadix2.net.telefonicaglobalsolutions.com - 0 | 1209 | 1209 | 2 | 9 | 108 | 75 |
| 104.44.53.48 - 39 | 483 | 297 | 0 | 8 | 43 | 6 |
| 104.44.49.51 - 79 | 295 | 62 | 0 | 37 | 61 | 35 |
| be-3-0.ibr02.got30.ntwk.msn.net - 37 | 499 | 317 | 33 | 44 | 182 | 34 |
| 104.44.31.116 - 20 | 683 | 548 | 33 | 45 | 185 | 34 |
| be-12-0.ibr02.lon22.ntwk.msn.net - 46 | 437 | 240 | 0 | 45 | 160 | 53 |
| be-13-0.ibr02.dub07.ntwk.msn.net - 21 | 678 | 542 | 0 | 39 | 134 | 55 |
| ae120-0.icr01.dub07.ntwk.msn.net - 0 | 1209 | 1209 | 32 | 36 | 97 | 50 |
| No response from host - 100 | 245 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 245 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 245 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 245 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 245 | 0 | 0 | 0 | 0 | 0 |
| 52.169.91.88 - 0 | 1209 | 1209 | 32 | 33 | 53 | 32 |
|________________________________________________|______|______|______|______|______|______|
Juego 2
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 1039 | 1039 | 0 | 0 | 15 | 0 |
| 192.168.144.1 - 1 | 1024 | 1020 | 1 | 1 | 25 | 1 |
|125.red-81-46-65.customer.static.ccgg.telefonica.net - 100 | 212 | 2 | 0 | 2 | 2 | 2 |
|18.red-81-46-66.customer.static.ccgg.telefonica.net - 29 | 491 | 352 | 2 | 3 | 24 | 3 |
|be1-400-grtmadte2.net.telefonicaglobalsolutions.com - 2 | 998 | 987 | 3 | 3 | 27 | 4 |
| 176.52.248.247 - 73 | 270 | 75 | 0 | 3 | 12 | 3 |
| lag-18.ear1.mad2.sp.lumen.tech - 0 | 1039 | 1039 | 3 | 6 | 51 | 4 |
| ae1.3107.edge6.dus1.neo.colt.net - 21 | 575 | 456 | 36 | 38 | 70 | 37 |
| universal-cdn.demarc.cogentco.com - 1 | 1028 | 1025 | 35 | 36 | 50 | 36 |
| 188.42.168.223 - 2 | 976 | 959 | 35 | 36 | 64 | 35 |
| 188.42.174.198 - 0 | 1039 | 1039 | 40 | 40 | 57 | 40 |
|________________________________________________|______|______|______|______|______|______|
En ambos casos me llama mucho la atención la pérdida de paquetes del 99% y del 100% en el tramo 125.red-81-46-65.customer.static.ccgg.telefonica.net, que por el nombre entiendo que es vuestro. ¿Con esos números sois capaces de decir que la línea funciona bien?
Quedo a la espera de respuesta.
Un saludo.
Buenas printertale
Los datos son similares a los anteriores, latencia final, pérdida de paquetes real final, son datos totalmente adecuados.
En el primer caso tenemos (juego 1)
Destino Final: 0% paquetes perdidos, 32 de minima, 33 de media. Ni Jitter, ni latencia alta ni paquetes perdidos
En el segundo caso tenemos (juego 2)
Destino final: 0% paquetes perdidos, 40 mín y media. Ni jitter, ni latencia elevada ni paquetes perdidos.
-----------------------
Los nodos que haces referencia, creo que lo explique anteriormente, y es como funcionan estas herramientas: ping/tracert, ambas aprovechándose del uso del protocolo ICMP
Una herramienta tipo "PING", lo que hace es enviar un paquete especial ICMP de tipo Echo Request. Esto induce al destino (si no bloquea esas peticiones) a contestar con un ICMP Echo Reply. La herramienta que lo envía puede medir así el tiempo desde que envía el paquete Request hasta que recibe el Reply. El tiempo que pasa desde el envío hasta la recepción es lo que por regla general llamamos latencia. Realmente esto tan solo mide la latencia de transporte, no mide la latencia del procesamiento de los paquetes de tráfico real. Nos vale solo para tener una idea de lo que demoran los paquetes de datos en llegar a destino.
Una herramienta tipo "TRACERT", se aprovecha tb del protocolo ICMP pero de otro modo. Los paquetes IP tienen un campo llamado TTL o tiempo de vida. Cada vez que un paquete pasa por cualquier nodo de red (punto intermedio) su valor se decrementa en 1, si llega a cero lo descarta. Esto no tiene mayor problema, el secreto es que cuando un nodo o punto intermedio decrementa el valor en 1 y como resultado da cero y lo descarta, devuelve al origen del paquete un mensaje ICMP especial que indica TTL excedido. Dado que quien responde con dicho mensaje puede ser cualquier punto intermedio, podemos aprovecharnos de esto para localizar cada nodo/salto intermedio. Como? Pues una herramienta tipo tracert envía primero un paquete a destino con un TTL = 1. Al pasar por el primer nodo (nuestro Router por lo general) lo va a decrementar en 1, como es cero lo descartará y avisará al equipo que descartado por TTL, el equipo puede ver que el origen del paquete es el Router. Ahora envía otro con TTL2. En este caso el paquete pasa normal el Router, pero es el segundo salto el que al decrementar en 1, será cero. Ahora es ese segundo nodo quien envía el paquete ICMP al origen. La herramienta tiene ya por tanto 2 saltos, con sus IPs... y así sucesivamente hasta que quien le responde es precisamente la IP final.
Bien, cual es el problema? Realmente no hay ninguno, lo que pasa es que estas dos utilidades que se usan para realizar este tipo de estadísticas (pingplotter, winmtr...) dan por sentado que los nodos intermedios y finales siempre van a contestar de forma correcta con un ICMP Reply en el caso de ping o con un paquete de TTL excedido en caso de tracert. Y el 90% de las veces así es. No obstante, para evitar abusos y ahorrar anchos de banda, es habitual que nodos intermedios sobre todo bloqueen completamente o parcialmente estas respuestas. Y esto es una faena, porque nos impide tomar en ese nodo particular datos realistas. A veces es un bloqueo completo, estos son los más fácil de ver, cuando tenemos un nodo intermedio que dice 100% paquetes perdidos por ejemplo o no response from host. Otras veces son discriminaciones o moderaciones, bloquear el 10%, el 50%, el... cada nodo se configura de cualquier modo. La mayoría de los Router domésticos incluso suelen hacer esto tb en cierto modo con los ping.
--------------
Entonces si hay nodos que no son fiables, como podemos saber si realmente existen pérdidas de paquetes o latencias raras en esos nodos? Fácil. Si lo que nos importa es el comportamiento general, miramos el final, si el final dice 0% paquetes perdidos son 0% paquetes perdidos, porque antes ha tenido que pasar por todo lo anterior!! Si existiese una pérdida real de un 10% por ejemplo, ese 10% se iría arrastrando hacia abajo hasta el destino final. Lo mismo pasa con la latencia. SI un nodo dice que la latencia es de 500ms, pero el destino final es de 50ms, sabemos que ese nodo intermedio no le están llegando bien los ping, o simplemente los están filtrando a medias.
Esto es lo que pasa con los nodos que indicas de Movistar. Si ese 99% fuese real, o el 29 o el... todo ello se vería arrastrado hacia abajo, porque esto es una "cadena" a fin de cuenta, los paquetes para llegar al salto 10 tienen que pasar antes por todos los anteriores, y si alguno de ellos se han caído 4, esos 4 van a aparecer caídos igualmente en los siguientes. Piensa en una carrera en la que salen 10 personas a correr y diferentes puntos de control. Por el primer punto pasan los 10, en el segundo tramo se caen 2 y siguen 8. En el segundo punto de control por tanto se cuentan 8. Si se cae un tercero en el siguiente trammo el punto de control 3 va a contar 3 menos en total (2 del segundo y 1 del tercero). Cuando llegan a la meta de los 10 que salieron a lo mejor solo llegan 4, luego se contabilizan 4. Si miramos solo el destino final y llegan 4 de 10, no podemos saber donde se han caído. Por eso usamos estas herramientas, para que nos digan DONDE se han caído. En cambio, si el destino nos dice que de 10 que salieron llegaron 10, no se ha perdido nadie por el camino, en todo caso un punto intermedio ha contado mal o un participante llegó con mucho retraso y ya no lo contaron o... pero llegar llegaron los 10.
---------
No veo que exista ningún problema en transmisión de datos, ni en la red de Movistar, in en redes intermedias ni en destino final. Si esos problemas siguen presente en esos momentos, o es en el equipo de origen o en los equipos de destino, o que el destino, después de llegar los paquetes allí, estén por otro lado enrutando el tráfico por una red interna o cualquier historia similar. Pero en lo tocante a tus paquetes de datos desde que salen de tu equipo hasta que llegan a destino, cero problemas. Si existiese problema en ello, estas herramientas nos lo dirían o mostrarían pérdidas de paquetes reales arrastrados hacia abajo, o latencias altas, o un jitter muy elevado o... pero nada de eso pasa, ni siquiera existen picos altos estadísticamente consistentes.
Saludos.
Buenas tardes Theliel
Voy a volver a escribir el mensaje porque parece que un moderador ha decidido que el mensaje era SPAM, cuando ni siquiera he nombrado los nombres de los juegos para no crear polémica. Eso sí, esta vez guardo el texto en un bloc de notas antes no sea que vuelvan a considerarme SPAM... Espero que haya sido un error y no que estén moderando respuestas que aportan pruebas y piden aclaraciones.
Como decía, pensé que estabas de permiso o liado con otras cosas, ya que no me contestaste a la pregunta de por qué si el problema está en el punto inicial o final, todo funcionaba ok cuando aislaba ese punto y conectaba el móvil como módem. Espero que ahora que has vuelto puedas contestarme a este aspecto.
Dicho esto, y también relativo a la conexión del móvil como modem, como persona de ciencias y empírica que soy, me gusta encontrar el por qué de las cosas, la raíz de los problemas y actuar sobre ellos una vez descubierto. Para respaldar mis afirmaciones acabo de conectar el móvil como modem y he repetido la prueba de hace unas horas, estos son los resultados.
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 172.20.10.1 - 0 | 1063 | 1063 | 0 | 0 | 13 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| 10.243.215.161 - 1 | 1047 | 1043 | 10 | 22 | 49 | 17 |
| 10.243.213.42 - 1 | 1055 | 1053 | 8 | 21 | 137 | 38 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| 76.red-80-58-88.staticip.rima-tde.net - 5 | 896 | 852 | 9 | 22 | 61 | 13 |
|10.red-81-46-7.customer.static.ccgg.telefonica.net - 1 | 1059 | 1058 | 9 | 21 | 72 | 29 |
|gramadix2-ae10.net.telefonicaglobalsolutions.com - 71 | 282 | 84 | 0 | 21 | 38 | 12 |
| 176.52.248.250 - 36 | 445 | 287 | 0 | 22 | 152 | 13 |
|microsoft-be10-grtmadix2.net.telefonicaglobalsolutions.com - 1 | 1048 | 1044 | 9 | 25 | 95 | 34 |
| 104.44.53.60 - 1 | 1055 | 1053 | 9 | 20 | 68 | 17 |
| 104.44.49.43 - 75 | 271 | 70 | 0 | 53 | 90 | 63 |
| be-3-0.ibr02.got30.ntwk.msn.net - 16 | 666 | 564 | 40 | 55 | 224 | 83 |
| 104.44.31.116 - 7 | 856 | 802 | 40 | 63 | 228 | 53 |
| be-12-0.ibr02.lon22.ntwk.msn.net - 46 | 382 | 209 | 0 | 58 | 188 | 52 |
| be-13-0.ibr02.dub07.ntwk.msn.net - 4 | 929 | 894 | 0 | 57 | 182 | 43 |
| ae124-0.icr03.dub07.ntwk.msn.net - 1 | 1043 | 1038 | 39 | 52 | 110 | 62 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| 52.169.91.88 - 0 | 1063 | 1063 | 39 | 49 | 79 | 55 |
|________________________________________________|______|______|______|______|______|______|Qué raro que me hayas explicado que hay nodos que descartan tráfico ICMP y el mismo nodo, o equivalente (XX.red-YY-YY-YY.customer.static.ccgg.telefonica.net) antes diera una pérdida de paquetes del 99% y ahora sólo del 1%...
¿Alguien tiene alguna aclaración de por qué un nodo descarta el 99% del tráfico ICMP si estoy conectado por fibra y el 1% si estoy conectado a través de móvil? Yo no se la encuentro.
Lo que me lleva a mis conclusiones:
- La conexión detecta que estoy conectado desde una fibra y descarta mis paquetes (no muy lógico en una empresa que se dedica a vender fibra)
- Efectivamente hay problemas en la conexión cuando estoy conectado por fibra (lo que vengo manteniendo desde agosto del 2024)
Dejo la conclusión del mago a parte no sea que eso haya sido el SPAM.
De hecho, en tu contestación anterior has dado con la clave, copio y pego de tu respuesta:
..."En cambio, si el destino nos dice que de 10 que salieron llegaron 10, no se ha perdido nadie por el camino, en todo caso un punto intermedio ha contado mal o un participante llegó con mucho retraso y ya no lo contaron o... pero llegar llegaron los 10."...
Esto es exactamente lo que me pasa a mí, cuando el corredor llega con mucho retraso y "no pasa" por el punto de control 3 pero sí llega a la meta:
- Si el servidor de destino es decente, cuando se descongela la conexión, vuelve al instante real a una velocidad de x20 (el punto de control le da igual si un corredor pasa por ahí o no)
- Si el servidor es normal, si en x segundos no pasa el corredor que debería pasar, cierra el punto de control y se le acaba la carrera (te echa del servidor, timeout de manual).
Por eso no consigo entender cómo habiendo descrito tan bien el problema que sufro, todos siguen pensando que como llegan todos los corredores a meta es que todo está bien, cuando insisto en que hay problemas en los puntos de control de la carrera y tanto juegos como trabajo se ven altamente afectados por este problema.
Espero haber aclarado dudas acerca del problema y quedo a la espera de respuesta.
Muchas gracias por tu tiempo.
Un saludo.
Buenas printertale
Perdona, perdí el hilo y no te contesté,
Cuando conectas el móvil para la conexión, las rutas cambian, el tráfico le llega al servidor por otro camino diferente e incluso enrutado por una red interna diferente que tengan a otros equipos diferentes. La configuración del móvil como conexión es también diferente, por ejemplo el MTU puede ser bastante menor que el MTU de una conexión fija. No podemos saber como los datos son tratados ni en origen ni en destino, tan solo podemos saber con un tracert/ping que es lo que pasa entre medias... si pasa algo.
--------
Respecto a tu tracert, es lo mismo. Diferentes rutas, diferentes nodos. Por lo general los nodos que discriminan el tráfico ICMP es dependiendo de multitud de factores. Como te digo, si tuvieses un 99% de pérdidas, lo notarías no con el juego, lo notarías en todo porque sería totalmente insufrible TODO, y para nada sería una cuestión de unos segundos. Un 99% implcia que de 100 paquetes se pierden 99, todo el tiempo, constantemente. Si fuese cierto obviamente. Y por cierto, es bueno el querer saber las cosas y realizar pruebas, eso denota un mínimo de interés, y la mejor forma sin dudar de adquirir conocimiento, de lo contrario uno no se hace nunca preguntas que puedan ser de interés, entre otras muchas cosas.
Respecto a tus conclusiones:
1º. No se puede detectar que tipo de conexión usas, para Movistar o cualquier otro ISP, el tráfico es tráfico, ni más ni menos. Es más, por legislación misma, no se puede tratar una conexión de un modo u otro. Aunque esto último tiene cierta... "trampa", porque las conexiones móviles si es cierto que se rigen por normativa ligeramente diferente, y de echo por defecto todas usan CGNAT , pero en definitivas y obviando detalles específicos, no, no se puede saber si es Fibra, DSL o que... tu ISP sí, obviamente, es el tuyo, sabe siempre como y cuando te conectas, lógicamente
2º. En los datos aportados, no se muestra problema alguno. Es más, tu propia prueba lo denota. Doy por sentado que estás usando un móvil que también usa la red de Movistar para ello. Es decir... sigues usando el mismo ISP, su misma red, su misma infraestructura... si existiese un problema con el ISP... no te pasaría lo mismo usando la red móvil?? Como nota, algo que la inmensa mayoría por alguna razón desconoce, las conexiones por datos móviles no usan satélites ni esas historias, tu conexión de datos va a un repetidor cercano, que va a la red de fibra del ISP. O dicho de otro modo, tanto la conexión por datos móviles como la conexión de fibra de tu casa, incluso si fuese una conexión DSL, comparten el grueso de toda la red e infraestructura. Las diferencias son pequeñas... en el caso de la conexión DSL a Fibra los primeros 1-2 saltos, en el caso de conexiones de datos pueden ser 2-3 saltos, nada más. Es más... prueba que el nodo por el que pasa sea igualmente parecido. No creo que sea exactamente el mismo por la propia arquitectura de la red, y sería muy muy casual que se enrutase exactamente por el mismo sitio en la red del ISP, pero poco más.
------------
Otro modo de comprobar todo ello, te invito a realizar pruebas tipo tracert/ping a un sin fin de destinos que nunca te den problemas, y verás como es totalmente habitual y normal pérdidas enormes en nodos intermedios... incluso en juegos de todo tipo, y no existe problema ni incidencia de ninguna clase.
Un ejemplo simple que acabo de realizar a wikipedia.org
|-------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - %% | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 140 | 140 | 0 | 0 | 17 | 0 |
| 192.168.144.1 - 0 | 140 | 140 | 1 | 1 | 17 | 1 |
| 157.red-81-41-225.staticip.rima-tde.net - 0 | 140 | 140 | 1 | 2 | 17 | 2 |
| No response from host - 100 | 164 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 146 | 0 | 0 | 0 | 0 | 0 |
| ae-0-400-grtmadde3.net.telefonicaglobalsolutions.com - 48 | 74 | 39 | 0 | 9 | 17 | 8 |
| 5.53.6.46 - 67 | 75 | 25 | 0 | 9 | 10 | 9 |
| 94.142.107.207 - 0 | 140 | 140 | 9 | 11 | 35 | 10 |
| bcn-b1-link.ip.twelve99.net - 0 | 140 | 140 | 16 | 17 | 30 | 17 |
| mei-b5-link.ip.twelve99.net - 0 | 140 | 140 | 24 | 25 | 88 | 25 |
| wikimedia-ic-370330.ip.twelve99-cust.net - 0 | 140 | 140 | 23 | 24 | 38 | 23 |
| et-0-0-48.asw1-b12-drmrs.wikimedia.org - 36 | 112 | 72 | 23 | 106 | 3639 | 3639 |
| text-lb.drmrs.wikimedia.org - 0 | 132 | 132 | 0 | 24 | 25 | 24 |
|_________________________________________________|______|______|______|______|______|______|Fíjate en los nodos 4 y 5, o incluso en el penúltimo con un 36%. Y sé perfectamente que no hay pérdida alguna, puedo correr un analizador de paquetes, ir actualizando la web constantemente, y todos llegan.
Este es a google.es
|-------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - %% | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 1034 | 1034 | 0 | 0 | 21 | 0 |
| 192.168.144.1 - 0 | 1034 | 1034 | 1 | 1 | 25 | 2 |
| 153.red-81-41-225.staticip.rima-tde.net - 0 | 1034 | 1034 | 2 | 2 | 13 | 3 |
| No response from host - 100 | 3275 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3264 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3551 | 0 | 0 | 0 | 0 | 0 |
| 81.173.106.65 - 0 | 1034 | 1034 | 8 | 9 | 25 | 10 |
| 192.178.110.155 - 0 | 1034 | 1034 | 8 | 10 | 25 | 10 |
| 142.250.213.127 - 0 | 1034 | 1034 | 8 | 8 | 14 | 9 |
| mad07s23-in-f3.1e100.net - 0 | 1034 | 1034 | 9 | 9 | 15 | 9 |
|_________________________________________________|______|______|______|______|______|______|Diferentes saltos en 100% de pérdidas
Un servidor de estado de epicgames (ping-nae.ds.on.epicgames.com)
|-------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - %% | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 30 | 30 | 0 | 1 | 15 | 0 |
| 192.168.144.1 - 0 | 30 | 30 | 1 | 3 | 20 | 1 |
| 153.red-81-41-225.staticip.rima-tde.net - 0 | 30 | 30 | 2 | 2 | 4 | 3 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| ae-0-400-grtmadde3.net.telefonicaglobalsolutions.com - 27 | 19 | 14 | 8 | 9 | 10 | 9 |
| 94.142.123.10 - 4 | 26 | 25 | 24 | 25 | 28 | 24 |
| 94.142.127.10 - 0 | 30 | 30 | 102 | 103 | 104 | 103 |
| 176.52.252.7 - 0 | 30 | 30 | 105 | 107 | 132 | 106 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| ec2-44-192-143-240.compute-1.amazonaws.com - 0 | 30 | 30 | 106 | 106 | 108 | 106 |
|_________________________________________________|______|______|______|______|______|______|En este caso tenemos 3 de 100, uno de 27, uno de 4... todas esas pérdidas no son reales, el tráfico llega perfectamente.
----------------------
Dices:
"Esto es exactamente lo que me pasa a mí, cuando el corredor llega con mucho retraso y "no pasa" por el punto de control 3 pero sí llega a la meta"
No, da exactamente igual el retraso que lleve, si no se pierde/bloquea, pasa. Si de pronto llegan todos como dices, es que no se ha perdido absolutamente nada por el camino, Es más, la latencia media lo indica igualmente.
Hay algo que estás perdido de vista. La latencia la cuenta el propio equipo desde que envía un paquete hasta que recibe contestación de ese paquete. La latencia no mide el tiempo de ida o el tiempo de vuelta. La latencia mide el tiempo de ida y vuelta!! Es decir, envía un paquete y se pone el crono en marcha... y lo para al llegar la contestación.
Si envía 100 paquetes y el destino contesta a los 100 paquetes con una media de 30ms (me estoy inventando los datos), da exactamente igual lo que haya pasado entre medias, porque el equipo puso el crono cundo salieron cada uno de esos paquetes y lo ha parado cuando uno a uno esos paquetes han ido llegando, y la media es 30ms. Si por el motivo que fuese hubiese existido un retraso de X, pongamos 3 segundos!! Esos 3 segundos quedan recogidos en la latencia final, no serían 30ms de media, sería un valor muy elevado, o al menos un jitter muy elevado. Es por eso que estas herramientas nos ayudan tanto, por lo que realmente están midiendo.
Por eso usamos un tracert junto a un ping, porque hay segmentos de una red en los que los paquetes pueden efectivamente tardar más o tardar menos, y es importante ver esos segmentos cunado hay problemas. Pero cuando hay problema, porque si de punta a punta no existe tal problema... no hay problema por ende en el camino, o existe un problema en origen o en destino, pero no en tránsito.
Saludos.
Buenas tardes Theliel
Pensé que estabas de permiso, o liado con otras cosas, ya que no me contestaste cuando pregunté cómo podíais explicar entonces que si el problema estaba en mis equipos o en el servidor final por qué todo iba genial si aislaba la fibra y conectaba el móvil como modem. Espero que ahora que estás de vuelta puedas aclararme este punto.
Dicho esto, y siguiendo con el tema, yo soy una persona de ciencias, muy empírico, y me gusta encontrar el por qué de las cosas. Tú me dices que ese 99% o 100% de pérdida de paquetes en xxx.red-yy-yy-yy.customer.static.ccgg.telefonica.net no es relevante y que si está configurado así pues que no escucha los Echo Request y no responde. Bien, ¿entonces cómo explicas que si conecto el móvil como modem obtenga que en lugar de 99% da un 5% de pérdida de paquetes?
Como no me gusta hablar sin datos que respalden mis afirmaciones, acabo de sacar la misma prueba de hace un rato pero ahora mismo tengo el móvil como modem en lugar de la fibra, estos son los resultados.
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 172.20.10.1 - 0 | 1063 | 1063 | 0 | 0 | 13 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| 10.243.215.161 - 1 | 1047 | 1043 | 10 | 22 | 49 | 17 |
| 10.243.213.42 - 1 | 1055 | 1053 | 8 | 21 | 137 | 38 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| 76.red-80-58-88.staticip.rima-tde.net - 5 | 896 | 852 | 9 | 22 | 61 | 13 |
|10.red-81-46-7.customer.static.ccgg.telefonica.net - 1 | 1059 | 1058 | 9 | 21 | 72 | 29 |
|gramadix2-ae10.net.telefonicaglobalsolutions.com - 71 | 282 | 84 | 0 | 21 | 38 | 12 |
| 176.52.248.250 - 36 | 445 | 287 | 0 | 22 | 152 | 13 |
|microsoft-be10-grtmadix2.net.telefonicaglobalsolutions.com - 1 | 1048 | 1044 | 9 | 25 | 95 | 34 |
| 104.44.53.60 - 1 | 1055 | 1053 | 9 | 20 | 68 | 17 |
| 104.44.49.43 - 75 | 271 | 70 | 0 | 53 | 90 | 63 |
| be-3-0.ibr02.got30.ntwk.msn.net - 16 | 666 | 564 | 40 | 55 | 224 | 83 |
| 104.44.31.116 - 7 | 856 | 802 | 40 | 63 | 228 | 53 |
| be-12-0.ibr02.lon22.ntwk.msn.net - 46 | 382 | 209 | 0 | 58 | 188 | 52 |
| be-13-0.ibr02.dub07.ntwk.msn.net - 4 | 929 | 894 | 0 | 57 | 182 | 43 |
| ae124-0.icr03.dub07.ntwk.msn.net - 1 | 1043 | 1038 | 39 | 52 | 110 | 62 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 215 | 0 | 0 | 0 | 0 | 0 |
| 52.169.91.88 - 0 | 1063 | 1063 | 39 | 49 | 79 | 55 |
|________________________________________________|______|______|______|______|______|______|Vaya, en este caso, la pérdida de paquetes en 10.red-81-46-7.customer.static.ccgg.telefonica.net es del 1%... curioso. Este nodo (o uno equivalente) hace unas horas estaba descartando el 99% de mi tráfico ICMP.
Esto me lleva a dos dudas:
- Esos nodos "saben" que mi conexión proviene de una conexión de fibra y descartan los paquetes, algo ilógico y contraproducente en una empresa que se dedica a vender fibra.
- Efectivamente si estoy conectado desde una fibra existen problemas en el tráfico, lo que hace que sufra los problemas que llevo varios días describiendo en este hilo, cosa que no ocurre con el móvil como modem.
- Extra: Lo hizo un mago
Dejando las coñas a un lado, que esto es muy serio, aunque no lo creas me estás dando la razón, lo que pasa que no quieres entender cuál es el problema que sufro, copio y pego de tu última respuesta:
..."En cambio, si el destino nos dice que de 10 que salieron llegaron 10, no se ha perdido nadie por el camino, en todo caso un punto intermedio ha contado mal o un participante llegó con mucho retraso y ya no lo contaron o... pero llegar llegaron los 10."...
Efectivamente este es el problema que tengo y lo has descrito a la perfección. Si el servidor al que estoy conectado es "bueno" y mantiene la conexión a pesar de todas las cosas, cuando "vuelve" la conexión todo lo que estaba congelado ocurre en la pantalla a un x20 de velocidad, recuperando la situación normal. Si el servidor no es tan decente, no todos los juegos son así de buenos, directamente si pasa x segundos desde que recibe el último paquete te echa de la partida, timeout.
Ese es mi caso, algunos juegos en el punto de control 3 como el corredor (paquete) llega con mucho retraso acaban la carrera y le dan por eliminado (timeout). En otros les da igual, cuentan que por ahí no ha pasado ningún corredor y se van a otra cosa, pero luego, después del retraso llega a meta (poniendo la velocidad del juego a x20) y aquí no ha pasado nada.
Lo que me gustaría entender es por qué, sabiendo lo que ocurre y siendo capaz de explicarlo tan bien en tu ejemplo, nadie cree que esto sea un problema y la solución siga siendo aquí todo esta ok, cuando insisto de nuevo, esto no es así.
Puede que al final el 100% de los paquetes lleguen a destino, pero pega cortes entre medias y no es viable ni trabajar así ni jugar así.
Gracias por tu tiempo.
Un saludo.
Hola printertale
Gracias a Theliel por la información.
Con la información que te han indicado, ¿Se ha podido comprobar si funciona?.
Quedamos al pendiente de tu respuesta.
Un saludo.
Nicoll.
