Hola, durante las últimas 1 o 2 semanas, la liga no se puede jugar, tengo una pérdida de paquetes muy alta, me comuniqué con el soporte técnico de RIOT Games t2 y t3 y me confirmaron que es un problema del ISP con una pérdida de paquetes como se muestra en el trazador de ping, es obvio. Nunca tuve este problema con movistar, pero necesito una solución porque me gano la vida haciendo streaming y no puedo jugar y esto también afecta mi trabajo. También hice un ticket de soporte y todavía estoy esperando un técnico, pero espero recibir ayuda más rápido aquí.aquí están los enlaces a las fotos de las pruebas y del equipo de soporte de riot t2https://ibb.co/rs42Hz0https://ibb.co/ypwY86Yhttps://ibb.co/RYgn7xGhttps://ibb.co/ZxTRstj

Hola jadalisa Debemos esperar a que un moderador apruebe el contenido multimedia para su visualización.Un saludo.

Buenas jadalisa Pues me temo que, como es habitual, instan a culpar a todos menos a ellos mismos. Por suerte tus capturas son prueba de de que no existe problema alguno por parte del ISP. Es más, en sus propias contestaciones se pueden ver perfectamente como en igualdad de condiciones culpan a unos pero no a ellos. Y ahora te desgrano todo esto, obviamente. A diferencia de, a mi me gusta explicar las cosas. En primer lugar, y más importante, es que la latencia o la pérdida de paquetes real es acumulativa. Esto es de sentido común, si en el primer salto se pierden 5 paquetes de los 10 que se envían, en el segundo salto solo podrán pasar 5 como mucho (porque se perdieron ya 5 en el primero), y si en ese seguro se pierden otros 3, en el tercer salto solo podrán llegar 2. Eso implica que en el primer salto veríamos una pérdida de un 50%, en el segundo veríamos una pérdida de un 80%, el tercer salto aparecería una pérdida del 80%. La latencia es similar, es acumulativa, si en el primer salto existe un retraso de 5ms de media, en el segundo salto veremos como mínimo un retraso de 5ms, que es el retraso que ya se aplicó en el primer salto. Esto es totalmente obvio. Es cierto que dado que una red es un ente dinámico y que es imposible enviar infinitos paquetes en un tiempo finito, no podemos tener una estadística perfecta, y a veces hay algunos saltos que puedan parecer que tienen ligeramente más latencia que otros, pero es solo debido a la imposibilidad estadística. Pero a groso modo, se ve perfectamente una tendencia. Dicho esto, si no te importa, analizo tu tracert, empiezo por el primero, pero realmente es similar al segundo: Lo primero que hacemos siempre es mirar el salto final, para ver la latencia media y la pérdida de paquetes, si existe. Tenemos el servidor de RIOT 162.249.72.1. ¿Problema? Que dicho servidor no está configurado para responder al tráfico ICMP, ni a los Echo Ping ni a la respuesta ICMP por TTL excedido, que es lo que usan las herramientas ping/tracert. Es por este motivo por el que aparece un 100% de pérdida y no hay latencia. Eso no significa que ese host no exista, es totalmente legítimo que un nodo quiera evitar responder a este tipo de tráfico, aunque a veces es cuanto menos sospechoso, sobre todo si es un punto final, dado que no podemos ver nada más allá de ese punto, no podemos saber nada más. Dado que no podemos sacar información del servidor final porque RIOT no los impide, sólo podemos miar el nodo anterior, en este caso con IP 176.52.248.251, que pertenece a la red de Telefónica. En este nodo lo que tenemos es una latencia media de 6.2ms y una pérdida de paquetes de 0%. Dicho de otro modo, antes de entrar en la red de RIOT, no existen pérdidas de paquetes reales ni una latencia elevada. Sin más. Aquí podríamos concluir el análisis. Pero como he dicho que me gusta explicar las cosas, voy a explicarte porque existen nodos intermedios en los que aparentemente existen supuestas pérdidas de paquetes, aunque la respuesta ya la he dado anteriormente al explicar por qué el nodo de RIOT lo hace. Un nodo no tiene por qué responder con tráfico ICMP. Y sin esas respuestas no podemos hacer nada. Muchos nodos directamente las bloquean, como podemos ver en los saltos 4/5/8, algunos nodos pueden no bloquearla y solo discriminar el tráfico ICMP, con el nodo 3. Pero... ¿como podemos estar seguro de que dichos nodos realmente no hay una pérdida de paquetes reales? Simple, si realmente existiese una pérdida de 85% en el nodo 3, o de un 100% en el nodo 4, no habría más tracert, la conexión se quedaría ahí, porque se habrían perdido todos los paquetes, no habría nada más. Sabemos que esto no es así porque en el salto 6 y 7 no existe tal pérdida. Eso quiere decir simple y llanamente que en el resto de nodos simplemente hay o un bloqueo completo o parcial, exactamente igual que hace el nodo de RIOT. Es interesante como en la contestación que hace riot dice: "Hay una pérdida visible de paquetes en los saltos 3,4 y 5..." en cambio no hace mención al salto 8, donde siguiendo su propia lectura existe una pérdida igualmente del 100%. ¿No te parece? Su 100% es menos válido que el 100% de otros nodos? Obviamente no es así, y ellos los saben... o quiero pensar que lo saben claro está, sino sería aun más preocupante :). -------- Respecto a segundo tracer es exactamente lo mismo, de nuevo el último nodo, el de RIOT bloquea toda comunicación, con lo que es imposible saber que pasa más allá. Si te das cuenta hay otros nodos con 100% de pérdidas, pero luego hay otros saltos después de ellos que podemos conocer, que sabemos que existen... el tráfico realmente está fluyendo. En cambio cuando vemos un 100% de pérdida en un punto final nos puede indicar diferentes cosas: a) Que realmente en dicho punto se esté perdiendo el 100% del tráfico b) Que dicho nodo bloquee las respuestas ICMP como ya he dicho c) Que dicho nodo no sea el final, sino que existan otros nodos e incluso un servidor final que son invisibles a nosotros, son invisibles porque ninguno responde al tráfico ICMP. En este caso particular es casi con total certeza la opción C. RIOT está ocultando de forma deliberada todo el tráfico que pasa a su red. Y esto lo digo porque si nos damos cuenta es el primer nodo de RIOT. El primer nodo de RIOT te aseguro que no es el servidor final, con lo que es sólo un nodo intermedio de ellos, a saber de cuantos más entremedias. Igual es un tracer aun más grande, no lo sé, lo digo simplemente basándome en el destino que has marcado como final, y desde luego ese nodo no puede ser el destino final real. Esto no es nuevo, no es la primera vez que vemos a RIOT ocultando sus huellas. El problema es que al hacerlo no tenemos ninguna herramienta que nos diga como de mal es el problema, y en que punto real está dentro de la red de RIOT. Pero si sabemos algo claro y obvio, que justo a la entrada de la red de RIOT el tráfico era correcta, no existía pérdida de paquetes ni existía problema de latencia. ----------- Así que, siento decirte, que los amigos de RIOT no están haciendo otra cosa que echar balones fuera, poniendo además de excusa (y esto es algo que me muestra la mala voluntad que hay por su parte) algo que ellos mismos aplican a su red, pero que por supuesto no señalan. Hay dos opciones. O realmente saben lo que está pasando y prefieren culpar a otro y actúan de mala fe, o realmente no tienen mucha idea de como se lee un tracer realmente, y/o como funciona el protocolo ICMP a la hora de realizar pings o las respuestas ICMP por TTL. Si te queda cualquier duda, dímelo, que con gusto te lo explico sin ningún problema. Saludos.

Buenas de nuevo jadalisa No respondo ni atiendo a mensajes privados como pongo en mi firma, me parece totalmente descortés para el resto de los usuarios del foro, puesto que lo que se dice en privado, queda en privado, y no suelo tener nada que ocultar :). Tan solo uso la mensajería privada aquí para cuestiones personales o muy concretas. Por otro lado, no pertenezco a Movistar ni tengo ninguna relación con ellos, soy un cliente al igual que tú. Dicho todo ello, si quieres, te explico un poco más todo, no me importa en absoluto. Aunque antes de ello, decirte que en este caso concreto Movistar no tiene que hacer absolutamente nada, ni contactar con nadie que no seas tú como su cliente. No existe ningún problema en su red a fin de cuentas. ¿Te imaginas una multinacional de tal magnitud yendo detrás de otras empresas para solucionarle los problemas a ellos? Movistar/Telefónica ya tiene sus propios problemas y asuntos, como para ir contactando con otras empresas para solucionar los problemas que tengan. Si esperas alguna actuación por ese lado, ya te digo que puedes esperar sentado, da igual que termines yéndote a otro ISP o no, es una cuestión mucho más sencilla que todo eso: No hay ningún indicio en los datos mostrados que indique un problema en su red. Y si esto lo veo yo como usuario y con las herramientas que tenemos a disposición, cuanto más podrán ellos saberlo 🙂 ----------------------------------- Dicho todo esto, lo único que puedo si quieres es explicarte mejor todo, al menos para que unos y otros no te tomen por tonto, y perdóname por la expresión, ya que no tienes ningún tipo de necesidad de tener que saber de estas cosas. Por desgracia muchos se aprovechan del desconocimiento técnico de la inmensa mayoría para decir/hacer lo que quieran. Voy a tratar de explicarte de forma sencilla y escueta (dentro de lo posible) los dos o tres conceptos importantes aquí. Latencia y Paquetes perdidos, Ping y Tracert. La latencia en las redes es ni más ni menos lo que llamamos el RTT, siglas inglesas, lo que viene a ser el tiempo de ida y vuelta (Si, el de vuelta también, la suma de todo). Es decir, desde que pulsas una tecla en tu teclado hasta que esa pulsación viaja por tu teclado, tu PC, el cableado de tu casa, el Router, la red de Movistar, las redes Intermedias, el servidor final, el procesado de dicha pulsación y todo el camino de vuelta. Los paquetes perdidos por otro lado es un poco más ambiguo, y hay que especificar bien a que nos referimos. Podemos hablar de paquete perdido real cuando enviamos un paquete de datos y este se pierde en el camino (de ida o de vuelta), ya sea por un cable roto, ya sea porque un dispositivo lo descarta o cualquier otra anomalía. En cambio, la mayoría de aplicaciones/utilidades no pueden detectar esto, y llaman paquete perdido a otra cosa. ¿En un mensaje de solo ida... como puedes saber si un paquete ha llegado? No puedes saberlo, porque si no esperas contestación, ha podido llegar o no. Así que se ingenian sistemas en el que se envía una "pregunta" para forzar una "respuesta". Así si la respuesta nos llega podemos decir que no se ha perdido el paquete, puesto que la respuesta ha llegado. Si la pregunta o la respuesta se perdiese en la ida o en la vuelta, tú no recibirías respuesta, ¿cierto? Pues así se asume estas herramientas y sistemas que hay una pérdida de paquetes. Pero realmente si te das cuenta no implica que se pierda un paquete, lo que miran es si llega o no llega la respuesta, que es bien diferente como ahora veremos. -------------------- Si entiendes bien estos dos conceptos, podemos explicar que es el "ping" o un "tracert". Ping es una utilidad/herramienta para medir la latencia entre un origen y un destino en redes. Su funcionamiento depende íntegramente en un protocolo llamado ICMP, que es usado para el diagnóstico de redes. Cuando lanzamos un PING lo que hacemos es enviar a un destino un paquete especial ICMP llamado "Echo Request", que lo que hace es que induce al destino a responder con un "Echo Reply" al origen. funciona así porque el protocolo ICMP es así. De este modo un equipo puede medir el tiempo desde que envía el Echo Request hasta que le llega el Echo Reply. Y magia!! Esa es la latencia, es el tiempo que ha tardado el paquete ICMP en ir y volver. El funcionamiento es más sencillo que un chupo. Solo tiene una pega. El destino usado para el "Echo Request" no tiene por qué estar configurado para responder con un "Echo Reply". Que entienda el protocolo ICMP no implica que tenga que contestar. Si quieres un ejemplo más visual de esto piensa en el teléfono móvil. El Echo Request sucede cuando te llaman por teléfono, el Echo Reply cuando respondes la llamada. Pero... tu puedes no coger el teléfono, ¿cierto? Pues aquí pasa lo mismo. Si no descuelgas el teléfono, la otra persona no puede medir el tiempo que has tardado en descolgar, porque no has descolgado. Tracert es otra utilidad para el diagnóstico de redes.En este caso Tracert se usa para conocer los nodos intermedios por los que transcurre los paquetes de datos desde el origen hasta el final. Esto es importante porque los datos no van de origen a destino directamente, en Internet pasan por multiples redes y nodos intermedios. Tracert nos permite intentar descubrir todos esos nodos intermedios, e incluso conocer la IP de ellos!!. Es increíble el ingenio detrás de esto. En este caso no se hace uso de un protocolo especial concreto, se puede realizar un tracert usando paquetes ICMP, paquetes TCP, paquetes UDP... la magia viene en otro lado. Un tracert explota un campo de la cabecera del protocolo IP llamado TTL. El protocolo IP es en esencia los que nos hace movernos por Internet. Este campo, TTL (Time to Live) existe para evitar que un paquete de datos pueda estar eternamente circulando por Internet. Parece una tontería, pero imagínate que existe por error un bucle en una red... el campo TTL lo evita. El campo TTL es un contador ni más ni menos, que decrece en 1 por cada nodo/salto por el que pasa. Los dispositivos de red están configurados para que si un paquete llega a TTL 0, se descarta. Por regla general, cuando un nodo descarta un paquete porque el TTL ha llegado a cero, informa al origen del paquete con un mensaje que dice algo así como "Paquete descartado por TTL excedido", y lo hace, sorpresa, a través del protocolo ICMP con "Time Exceded" Entonces, como funciona un Tracert? Bien, se aprovecha del campo TTL. Dado que cuando el TTL es excedido por lo general el nodo va a responder con un mensaje al origen ICMP, lo que se hace es envíar al destino un paquete con: TTL 1: El Router le restará 1, como es cero lo descarta e informa a tu equipo que lo ha descartado, tu equipo ya tiene la 1º IP, la de tu Router. TTL 2: El Router le resta 1, no es cero, lo pone en circulación. El siguiente nodo (posiblemente la centralita en este caso le resta 1, es cero, TTL excedido, envía mensaje ICMP al origen. Tu equipo ya tiene el salto 2, la centralita, y su IP. TTL 3+:... el proceso se repite indefinidamente hasta que la respuesta de TTL excedido le llega desde la misma IP de destino a la que lo estaba enviando. En este punto ya tiene todos los nodos intermedios. ¿Todos los nodos? Bueno, tendrá todos los nodos si todos ellos han respondido con el mensaje ICMP de TTL Excedido, si alguno de ellos no ha respondido porque no está configurado para hacerlo, para el equipo habrá un "agujero" del que no tendrá la IP ni datos. Y por qué sabemos que existe ese agujero? Simple, porque aunque no nos responda, cuando usamos el siguiente paquete con un TTL de +1, el siguiente si nos envía el mensaje, con lo que sabemos que hay un nodo ahí "oculto". ------------------------------------------------- Pues bien, hasta aquí lo complicado. Si eso lo hemos entendido solo hay que sumar ambas herramientas, que es lo que hace WinMTR y otras herramientas (pingplotter por ejemplo). Primero se realiza un tracert para conocer todos los nodos intermedios, y una vez tenemos las IPs de dichos nodos, podemos usar ping hacia ellos para conocer la latencia. Por qué existen "agujeros" o supuestas pérdidas de paquetes que no lo son y otros datos "confusos"? Realmente no son datos confusos, los datos son lo que son, el problema es una mala interpretación. Si el tracert no tiene respuesta por ejemplo de conocer el salto 5, no puede enviar ningún ping a él, así que la aplicación te muestra esto como un 100% de pérdida. No es que dicha pérdida exista, es que ni siquiera ha podido conectar con él. A veces si tenemos información del nodo y de su IP gracias al tracert, pero por el contrario el nodo bloquea las respuestas ICMP Echo Reply, completamente (de nuevo tendríamos un 100% de pérdida de paquetes) o parcialmente. En cambio, en ambos supuestos anteriores, no sería una pérdida de paquetes real, puesto que no se ha perdido ningún paquete. Más bien el nodo en cuestión no nos ha respondido intencionadamente, aunque los paquetes hayan llegado. Una pérdida de paquetes real es aquella en la que tus paquetes son como decíamos descartados o perdidos en la ida o en la vuelta. SI te das cuenta nada tiene que ver con lo otro, donde los paquetes sí llegan, y no se pierden a la vuelta, simplemente no se responde... Análogamente, como decía con la llamada de teléfono, no puedes asumir que la persona al otro lado del teléfono no lo coge porque está hablando con otro. Uno podría decir que es fácil saberlo porque si está hablando con otro te sale comunicando, ¿cierto? Sí, normalmente a lo mejor, pero ¿y si habilitas la llamada en espera? Quien llama no lo sabe, para el que llama tan solo aprecia que no le cogen el teléfono (paquete perdido), cuando a lo mejor simplemente tiene puesta llamada en espera y está por teléfono con otra persona. ------------ Como podemos saber entonces si la pérdida de paquetes o la latencia es real? Pues ya lo he dicho, es muy simple. Una carrera de obstáculos con 10 puntos de control en los que van cronometrando a los que van llegando. Tu sólo estás cronometrando en la salida sin ver que pasa en el resto de puntos de control, pero por radio cada punto de control te dice los tiempos de todos los que han pasado. Preparados, listos... ya!! Salen 100 participantes. Te van llamando los puntos de control por los que van pasando, y te informan de los 100 tiempos de cada uno, todo va bien, primer punto de control, segundo punto de control... Vaya!! En el tercer punto de control tan solo te dan 50 tiempos, que ha pasado con el resto de corredores? No lo sabemos aun... obviamente esperas a ver que pasa en el cuarto. En el cuarto punto de control te llegan ahora sí 100 tiempos de nuevo.. ¿Que es lo que piensas? a) Hay 50 corredores que hicieron trampa y se teletransportaron hasta el control 4 b) En el control 3 metieron la pata y bien, miraron para otro lado... Sabemos que los corredores han llegado al punto 4, con lo que no se han perdido ni les ha pasado nada, así que obviamente la opción lógica es la b, algo pasó en el punto 3 y no los contaron por cualquier motivo. Seguimos avanzando, control 5 bien, control 6... en el control 7 en cambio nos llegan solo 90 tiempos, faltan 10. Por supuesto pensamos que pueda pasar lo mismo que en el punto 3, esperamos el punto control 8, pero al llegar al 8 nos vuelven a mandar 90. Que está pasando? a) Doble descuido por parte del punto de control? Es posible, doble error, pero es posible b) Se nos han caído 10 concursantes en el camino Nos llegan los datos del punto 9 y ahora solo son 70, y en la meta tan solo logran contabilizar de nuevo 70. Bien, llegado a este punto damos por supuesto que en algún punto entre el control 7 y el 8 10 corredores mordieron el polvo, y que entre el 8 y el 9 se cayeron otros 20. Salieron 100, llegaron 70. Tú que estás en la linea de salida no puedes miar la meta, no sabes realmente cuantos llegaron, solo tienes los tiempos recabados de cada punto de control. Del mismo modo que en el control 3 das por sentado que se contó mal, en los controles anteriores parece ser que si que se cayeron, puesto que en el recuento final tampoco aparecían. ------- La pérdida de paquetes real es igual. Si existiese una pérdida de paquetes reales donde indicas, esta se vería reflejada en todos los demás puntos, al igual que los puntos de control de los corredores. Si en uno de los puntos aparecen todos los paquetes, es que obviamente en algunos puntos anteriores no se ha contado bien, los paquetes como los corredores no pueden teletransportarse 🙂 Más absurdo aun, cuando vemos el 100%, si existiese realmente un 100%, el tráfico se acabaría ahí, no habría más nodo ni más nada. Siento el tocho y espero que lo entiendas un poquito mejor, y que veas lo absurdo que te diga el supuesto servicio técnico de RIOT que es que hay cierta pérdida en ciertos puntos del ISP... cuando en el de ellos pone un 100% de pérdida (que tampoco es real que tengan un 100% de pérdida o no tendrías conexión directamente con ellos) Saludos.

Hola jadalisa Esperamos que con la explicación facilitada por Theliel (al que agradecemos siempre su apoyo y conocimiento) haya resuelto tus dudas. Un saludo Lidia.

@Theliel @Técnico-Movistar muchas gracias por la explicación, para mi estoy en el medio entre Movistar y riot, estoy pagando los dos y cada uno culpa al otro como siempre, entendí tu explicación pero por lo que veo claramente hay pérdida de paquetes en el hop 3-4 80% de pérdida de paquetes, 94.red-81-46-64.customer.static.ccgg.telefonica.net y 190.red-81-46-64.customer.static.ccgg.telefonica.net NOTA; Intenté usar Orange, Vodafone y Yiogo, no tuve ningún problema e hice la prueba de pingplotter y no aparece rojo en ningún salto de la prueba. También le pregunté a un amigo que tiene Movistar y me dijo que le está pasando exactamente lo mismo. problema, hice pruebas en su máquina y él también tiene rojo en los mismos saltos, no creo que esto sea ciencia espacial o necesito estudiar física, si todos los demás proveedores no tienen problemas y solo son usuarios de movistar entonces no lo sé. al final del día no me importa solo quiero que funcione y como no puedo cambiar de riot como proveedor puedo cambiar de movistar que me gusta mucho y no tuve problemas en el pasado, pero estoy esperando que los técnicos se comuniquen conmigo , si no pueden ayudar simplemente cancelaré el contrato. No tengo tiempo de ver quién tiene razón y quién no. No me importa, pero puedo ver la enorme línea roja en los saltos en Movistar que en todos los demás proveedores. no existe y el problema no existe, estoy perdiendo dinero todos los días, RIOT SUGERIÓ contactarlos a través de este portal https://www.peeringdb.com/net/5918 para solucionar el problema de enrutamiento, y no veo una razón por la cual no, así que háganmelo saber, no puedo ser La única persona que informó este problema, lo único es que el ping muestra que está bien, pero con la pérdida de este paquete no se puede reproducir.

League of Legends packet loss/LAG ( problema de routing )

27 Respuestas

jadalisa
Yo probé el VDSL
11-09-2023
Gracias de nuevo por tu esfuerzo, por favor no me confundas porque estoy muy enojado por no agradecer tu ayuda, porque estoy pagando mucho dinero para resolverlo, mi pregunta simple fue por qué con Orange no tengo este problema, pero entiendo si no puedes. Responda esta pregunta, solo necesito confirmación técnica sobre si vamos a analizar este problema o no, para saber qué hacer a continuación. Muchas gracias por el apoyo nuevamente.
Theliel
Yo probé el VDSL
11-09-2023
Buenas jadalisa

Te lo vuelvo a repetir, la pérdida de paquetes es acumulativa, en tu captura TAMPOCO HAY PERDIDA EN EL SALTO 7, QUE ES EL ÚLTIMO ANTES DE RIOT. SI EN EL SALTO 7 NO HAY PERDIDA DE PAQUETES, TU TRAFICO NO TIENE PERDIDAS EN SALTOS ANTERIORES.

En los saltos 1, 3 y 4 tienes

Salto 1: Tienes pérdida de paquetes en tu propia red local, los paquetes ni siquiera salen, con lo que se reenvían. ese porcentaje no aparece reflejado más allá. Seguramente por usar WIFI. Es culpa tuya ese problema

Salto 3 y 4: Discriminación del tráfico ICMP, NO EXISTE PERDIDA DE PAQUETES REALES, Y ASI QUEDA REFLEJADO EN SALTOS SIGUIENTES.

-----------

Repito que entiendo tu frustración compañero, pero por más que repitas lo mismo no va a cambiar la cuestión. Te he dicho lo mismo desde el primer post. Eres libre de creer o que estimes y de tomar las decisiones que creas conveniente, toda la información te la he ya explicado en varias ocasiones, eres libre de hacer con ella lo que estimes, creo que lo he explicado del mejor modo posible, tanto de forma resumida como detalladamente.

Personalmente no le veo ningún sentido seguir invirtiendo mi tiempo libre en repetir una y otra vez lo mismo, yo al menos doy por zanjado el asunto y me despido de este hilo,

Saludos y suerte.
jadalisa
Yo probé el VDSL
11-09-2023
Entiendo que riot oculta su IP, el mundo entero no se queja de que los usuarios de riot solo movistar tengan problemas, PUEDES ver CLARAMENTE que no hay pérdida de paquetes antes de la última IP en el análisis naranja, puedes ver con movistar que hay pérdida de paquetes en saltos 3 -4 -6, PERO ORANGE NO TIENE NINGUNA PÉRDIDA DE PAQUETES MIRA LAS 2 FOTOS + como dije POR QUÉ ORANGE NO HAY PROBLEMA y movistar = problema, alguien explica que esto es una prueba física y lo probé con la misma máquina pero con 2 ISP diferentes, no culpes riot es una broma la verdad, no hay excusa alguna, algo está pasando mal en movistar, ¿puede un técnico de movistar ver esto? Sólo necesito una confirmación de que no lo arreglarás, así que cancelo el contrato ahora mismo. No tengo tiempo para esto. Estoy perdiendo dinero a diario. Lo siento.
este EN LACE ES DE MOVISTAR = PACKETLOSS HOP 3-4, like
https://ibb.co/ypwY86Y
ESTE LACE DE ORANAGE
https://ibb.co/NtKSPqw
Theliel
Yo probé el VDSL
11-09-2023
Buenas jadalisa

Existe exactamente la misma pérdida de paquetes que con tu conexión con Movistar, LA MISMA, es decir, ninguna.

Aplicando tu misma lógica, aplicando exactamente tu mismo criterio, como ya te he dicho, vemos en este tracert un 100% de pérdidas de paquetes en la red de RIOT. Es decir, que ante exactamente el mismo principio, aplicas criterios diferentes de forma arbitraria.

Te lo repito, en tus pruebas mostradas, no existe ninguna pérdida real de paquetes. La explicación ya te la he dado, es simplemente discriminación de las respuestas ICMP, exactamente igual que hacen los servidores de RIOT. Simple y llanamente.

Saludos.
jadalisa
Yo probé el VDSL
11-09-2023
Hola, dime ahora que el problema no está resuelto, puedes ver claramente aquí en la foto que no hay ninguna pérdida de paquetes probando con naranja, también puedes ver cómo tengo un cable conectado de mi vecino a mi casa y funciona perfectamente. con Orange, no me importa cuál sea el problema, necesito una solución, por favor, POR QUÉ funciona con Orange y con mi fibra más cara de 50 euros en España (movistar) no puedo jugar, no creo que esto necesite ningún tipo de física o neurociencia, es claro que ORANGE,VODAFONE= FUNCIONA, MOVISTAR= NO FUNCIONA, dicho esto agradezco el empeño Theliel puesto en este post y respeto sus conocimientos.
https://ibb.co/2tPbZR7
https://ibb.co/NtKSPqw
Técnico-Movistar
Responsable Técnico
11-09-2023
Hola jadalisa

Esperamos que la información facilitada por Theliel (a quien agradecemos su colaboración) te haya resultado útil.

Un saludo.

Flor
Theliel
Yo probé el VDSL
08-09-2023
Buenas jadalisa

Eso ya te lo he explicado anteriormente compañero, está en el post anterior,

Saludos y suerte.
jadalisa
Yo probé el VDSL
08-09-2023
Técnico-Movistar Hola, no, no se ha solucionado, todavía no entiendo por qué este problema solo pasa con movistar, probé con oranage, vodafone y va perfecto, solo con gente que usa movistar, tengo el análisis de otra persona que usa movistar, la misma pérdida de paquetes. Como yo, necesito una respuesta de por qué solo le sucede a Movistar, no es una coincidencia, ¿cómo puedo decir que es culpa de disturbios si solo le sucede a Movistar pero el resto del mundo está bien?
https://ibb.co/c8WVqWR
Técnico-Movistar
Responsable Técnico
08-09-2023
Hola jadalisa.

¿Podrías confirmarnos si ha quedado resuelta tu consulta con la información facilitada por Theliel, al que agradecemos su aportación, por favor?

Un saludo.

Angela.
Theliel
Yo probé el VDSL
07-09-2023
Buenas jadalisa

Depende a que problema te refieras exactamente. Si te refieres a lo que muestra tu tracert/ping, no existe ningún problema con lo que no se puede valorar.

Si te refieres a que tienes más o menos latencia que otros usuarios, es complicado saberlo exactamente porque de nuevo la red de RIOT oculta todo lo que sucede más allá del nodo que lo bloquea todo.

No obstante, y como algo general, suele ser porque tienen problemas con sus Peer. Un proveedor de servicios/contenidos, como una empresa de juegos, de plataformas digitales como Netflix/Prime y tantas otras, no son ISP, son repito proveedores de contenidos. Estos para estar conectados al mundo requieren tener ciertas conexiones a otras redes troncales que puedan llevarle el tráfico de todas partes del mundo.

Un ISP como Movistar tiene por ejemplo decenas y decenas de Peer, porque su función principal es esa, dar acceso a Internet. Esto se traduce en que tu como usuario puedes alcanzar cualquier parte del mundo por diferentes sitios, no existe una ruta única. Así todo el tráfico de los ISP se pueden distribuir del mejor modo posible, y alcanzar más lugares.

Los proveedores de servicio/contenido no tienen esta capacidad, y se ven limitado enormemente a las conexiones que tienen hacia el exterior. No tienen decenas y decenas de conexiones, están mucho más limitados, y esto causa cuellos de botellas, porque todo el tráfico del mundo se ve envocado a un número mucho más limitado de "entradas". Esto se ve enormemente potenciado si no distribuyes bien la carga entre todas tus "entradas" en función del tráfico que llega por cada lado.

Te pongo un ejemplo simple, y no digo que sea la razón por la que pasa. Movistar tiene más clientes que otro ISP, y la puerta de RIOT por la que pasan es tan solo una. Por contra todos los que sean de Orange pasan por otra puerta diferente, pero son menos usuarios, con lo que no están tan apretados.

Hablo en términos simples, la cosa es mucho más compleja que todo ello. En este caso particular sabemos que no es un problema de Peer con Telefónica puesto que tenemos los datos del último punto de la red de Telefónica y los datos son excelentes, no existe problema. De echo en todo el tracert no vemos ningún tipo de problema, solo la incógnita de que pasará una vez llega a la red de RIOT.

Por desgracia como ya he dicho, RIOT oculta todo lo que pasa en su red (me pregunto por qué será), con lo que tan solo podemos hacer suposiciones.

-----------------

Como ya te he dicho Movistar no puede hacer nada porque no existe problema en su red. Si es motivo para que te vayas a otro ISP, eres libre de hacerlo, eso no va a cambiar lo que Movistar puede o no puede hacer. Movistar ni siquiera puede saber lo que pasa en la red de RIOT, eso tan solo lo pueden saber los de RIOT, Movistar puede llegar hasta el mismo sitio que tu puedes ver, lo que pasa en su red, nada más, y en su red todo es correcto.

Si quieres esperar que ellos te contesten, perfecto, ya te digo que son muchos muchos años en este mundillo para saber como funcionan las cosas. Si realmente pensase que es culpa de Movistar en este caso, te instaría a contactar con ellos y que lo solucionasen, ten en cuenta que yo como usuario y cliente me interesa también que todo funcione bien en su red, OBVIAMENTE!! Pero en este caso concreto no existe problema alguno... al menos en la red de Movistar.Igualmente en este caso en concreto tampoco puedo decir con seguridad que exista un problema en la red de RIOT, porque esconden estos datos. Movistar no esconde los datos, pueden verse, ahí están.

Ya el resto que quieras hacer o no, es cosa tuya compañero.

Saludos.

Foro

League of Legends packet loss/LAG ( problema de routing )

27 Respuestas

Contenido relacionado

Problemas de conexion League of Legends

Problemas router

Problemas de conexion en league of legends