Lag en league of legends.
A mi me pasa lo mismo tío y desde hace años y nunca me lo han solucionado. Podria preguntarte de que cuidad eres? A lo mejor vivimos en el mismo sitio
Foro
No, no se ha resuelto. Es claramente un problema de interpretación de las leyes de "neutralidad de la red" establecidas por la UE.
Esto ayudaría mucho.
Puedo entender esto porque las leyes no son claras. Sugeriría a Movistar que aclare con la UE y, si es necesario, que se ponga al regulador directamente sobre el asunto.
Buenas tu pesadilo
No funciona así compañero, y de eso sé bastante créeme, es mucho más simple que todo eso, y ya podemos dar gracias de que sea así. La cuestión de base es muy simple, no se puede dar ni un trato privilegiado ni penalizar ningún tipo de tráfico de forma discriminada. Dicho de otro modo, por mucho que mañana media España empezase a usar en Movistar sin parar P2P, Movistar no podría discriminar/penalizar dicho tráfico a expensas de otros.
Esto, como todo, tiene sus excepciones. Obviamente si el tráfico que se generase en un momento puntual fuese tal que estuviese saturando sus redes, tendría que tomar medidas temporales para que el resto del tráfico de la red no se viese afectada. Y en cualquier caso esto no sería una discriminación a dedo. Pero que ocurra esto es cuanto menos complicado. Los únicos escenarios donde esto puede ocurrir son en ataques DDoS pertrechados de forma externa, y dichas medidas vendrían a fin de cuenta para frenarlos/detenerlos.
con lo que a fin de cuenta, a efectos prácticos y realistas, Movistar, ni ningún otro ISP, bloquea/prioriza ningún tipo de tráfico en su red. Y si esto lo extrapolamos a una posible latencia o no de algunos juegos, es cuanto menos aun más absurdo, donde en absoluto es una cuestión de interpretación de leyes. Máxime si tenemos en cuenta que el tráfico generado por juegos es mínimo, estaría por debajo del todo en caudal, es irrelevante a nivel global. Con lo que creer o pensar que uno pueda tener más o menos lag en un juego porque el ISP pueda discriminar tráfico... pues me temo pero no es así.
Y de cualquier modo lo repito, quien realmente crea que tiene un problema de lantencia, WinMTR/PingPlotter contra el destino que crea que tiene el problema, almenos 200-300 paquetes por estabilidad, y copiar/pegar resultado. Simple y efectivo.
En las pruebas efectuadas y al destino especificado en el WinMTR anterior, la latencia es más que buena, aunque entiendo perfectamente que el destino especificado no es "real", en tanto y cuanto no es al destino que realmente estás conectado cuando juegas, solo es orientativa.
Ya he dicho que la inmensa mayoría de los casos, la latencia se acumula o en el Router debido al uso de WIFI, o en el peer final con la red de destino. Eso no quiere decir que de vez en cuando exista un mal enrutado inicial por parte de Movistar, o que incluso algún nodo de este esté congestionado y dando problemas. Por eso mismo usamos estas herramientas, porque si es así y existe un problema en la red de Movistar, se puede reportar y solucionar, de lo contrario no hay nada que hacer.
La gestión del tráfico no solo afecta la latencia.
Sabes que también es una pérdida de paquetes.
¿Por qué probar con ICMP cuando el juego utiliza principalmente protocolos UDP?
Es mejor probar con eso.
Puedo ver qué paquetes se eliminan con un rastreador de paquetes y muchas gracias a GVSP.
ICMP no mostrará los mismos niveles de pérdida de paquetes.
De hecho, mostrará cero pérdidas.
Para la persona informada, parece que a ICMP se le permite pasar sin obstáculos. Entonces esto puede causar resultados falsos.
Podemos ver esto cuando los nodos dejan de mostrar información cuando comienzan a mostrar pérdida de ICMP.Buenas tu pesadilo
Por supuesto, en momentos extremos una red puede descartar paquetes para estabilizar el tráfico, y esto también es medible perfectamente.
¿Por qué usar ICMP, y no UDP? Pues por una razón muy simple, me temo que no entiendes bien como funciona ICMP y su necesidad a la hora de realizar un tracert/ping.
Un Ping no es más que un paquete ICMP Echo request, que lo que hace es "inducir" una respuesta ICMP Echo Reply desde el destino. El protocolo funciona así, punto. Si el destino no bloquea específicamente las respuestas ICMP Echo Reply, enviará un paquete de vuelta ICMP. Y de ese modo el origen puede medir la latencia, que no es más que la suma del tiempo que ha tardado el paquete desde que se envió hasta que se recibió el Echo Reply. Esto puede simularse con UDP o cualquier otro protocolo programando por encima este comportamiento, pero nada más, UDP no es un protocolo orientado a conexión, por muchos paquetes UDP que envíes a un destino, a menos que específicamente el destino esté programado para responder algo, no lo va a hacer.
Y respecto al Tracert, no se requiere enviar ningún tipo de paquete especial al destino para tracear, puede ser udp, icmp, tcp... no importa, lo que se hace es jugar con el TTL del paquete, para obligar que uno a uno los nodos vayan descartando el paquete por TTL, es decir, induce una respuesta del nodo o destino a responder con un mensaje ICMP de TTL superado, y así poder conocer/descubrir la IP de los nodos intermedios.
En cualquiera de ambos casos, UDP no tiene nada que hacer en ello. Sí, puedes configurar un servidor final con algún protocolo de control que te de cierta información de lo que transmite el origen y el destino, pero NADA MAS, no te puede brindar ningún tipo de información en el tránsito, que es lo realmente importante por lo general.
ICMP si se sabe leer bien, te dice perfectamente la congestión y problemas que pueda existir en cualquier nodo entre tu equipo y el destino. Es un protocolo específicamente diseñado para ello y que se implementa casi de forma universal. Que a veces pueden verse supuestas pérdidas de paquetes que no lo son?? Sí, muchas veces, porque los nodos no tiene obligación de responder ICMP, o pueden responder de forma discriminatoria porque no están obligados. Pero aun con todo es de lejos el modo más eficaz y real de medir tanto la latencia como la pérdida de paquetes.
Cualquier otro sistema que se quiera usar es dependiente exclusivamente de origen y destino, lo cual tiene su utilidad para saber en todo casi si la cosa esta bien/mal/regular, pero no aporta nada que sea realmente importante, que es donde y por qué. Es lo que pasa cuando uno quiere fiarse de los protocolos y sistemas que usan los juegos por ejemplo, ellos te pueden decir que pasa X, que aun puedo asumir que sea verdad, pero no te dicen que ese X puede estar causado por su propio servidor o su propia red, o incluso la red del usuario.
Si ICMP muestra 0% pérdidas de forma consistente a destino final, quieras o no quieras verlo, implica que en todo el recorrido no se han perdido paquetes del tráfico, desde el Router hasta la respuesta del servidor final. Si existen pérdidas por encima de ello que sean reales, es debido en ese caso a que el servidor final o el equipo de origen tienen problemas, y eso no lo puede registrar ICMP, porque ICMP induce repito una respuesta automática en el destino, son datos QUE NO SE TIENEN QUE PROCESAR. Si el servidor/origen tienen algún problema en los propios equipos, ya sea a nivel de software, saturación o cualquier otra cuestión, es un problema del origen o del destino, no del tránsito.
Saludos.
