En este momento estás viendo Hablemos de lag: Qué es, cuales son sus causas y cómo solucionarlo.

Hablemos de lag: Qué es, cuales son sus causas y cómo solucionarlo.

Autor: Bitconion

Cuando de juegos online se trata, todos hemos experimentado ese maldito lag que nos arruina la partida.  Encontrar un culpable generalmente no es tarea difícil, sin embargo corregir el problema puede llegar a ser un verdadero dolor de cabeza si es que no se cuenta con los conocimientos necesarios así que para no confundirnos, vamos por pasos.

¿Qué es el lag?

Contenidos de la página

Antes de seguir hablando de lag debemos saber lo que significa. Y se trata de un retraso en la comunicación que hay entre clientes y servidores perceptible para el usuario ya sea de forma leve o muy marcada.

Sin embargo dentro de la comunidad gamer es común llamarle lag a la baja velocidad en el procesamiento o renderizado del juego ya que estos problemas suelen percibirse de forma muy marcada.

¿Cuáles son las posibles causas de lag?

Esta sensación de retraso, lentitud, tirones o cualquier otra que hayas experimentado puede tener diferentes causas y de estas puede ser una sola la que lo genera o una mezcla de varias. A continuación voy a listar las mas comunes:

Conexión

La latencia es el tiempo que tarda un paquete de datos en transferirse de un punto A a un punto B en este caso el punto A sería el dispositivo que usamos para jugar (PC, teléfono móvil, tablet, etc) y el punto B sería el servidor al que nos conectamos. Para determinar la latencia podemos usar el Ping.

El ping  es el tiempo que tarda un paquete de datos en ser enviado a un servidor y de regreso a su punto de origen, se mide en ms o milisegundos y entre más alta es la cifra es menor la latencia, esto quiere decir que si tenemos 40 ms hacia un servidor nuestra conexión podría ser considerada como excelente, sin embargo cuanto este ping supera los 120 podríamos considerarlo como una latencia media baja. Nota: Los problemas de lag derivados de un ping alto pueden variar dependiendo de la modalidad de juego y otros factores.

Ya que tenemos esta información un método simple para identificar si el lag es causado por latencia, sería revisar el Ping que tenemos hacia un servidor específico y compararlo con otros que se encuentren relativamente a la misma distancia y con esto podríamos apóyanos para identificar si la baja latencia es debido a mala conexión por parte del cliente, por parte de el servidor o debido a la distancia física que hay entre ambos ya que a mayor distancia, habrá un mayor ping. Sumado a lo anterior también podríamos testear nuestra conexión a internet con alguna herramienta web como speedtest.net en el caso de conexiones caseras o con speedtest-cli desde servidores  Linux.

Aunque por otro lado, un ping alto podría no ser estrictamente por una mala conexión y/o distancia. También podría ser debido a una mala administración del ancho de banda por parte del usuario o el servidor. Esto quiere decir que si nuestra conexión a internet es de baja velocidad y alguien más (O nosotros mismos) esta conectado a esta misma red y se encuentra generando un trafico alto esto haría que nuestro ping se eleve. Un ejemplo podría ser alguien subiendo o descargando archivos pesados o los servicios de streaming de videos o música.

Recursos

Al hablar de recursos me refiero a la capacidad de el procesador y/o memoria ram, este problema igual que el anterior puede ser tanto del lado del servidor como del lado del cliente.

Cliente: Si como clientes contamos con un equipo de características “bajas” este podría ser uno de los causantes del lag aunque por otro lado están las necesidades en cuanto gráficos de el juego. Si contamos con una tarjeta gráfica dedicada o si se usa la integrada al procesador. Específicamente hablando de Minecraft debemos recordar que aunque este juego no tiene exigencias gráficas altas (A menos que se use Shaders Mod o algo similar), el consumo de recursos del procesador suele ser muy alto.

Servidor: De este lado el problema podría ser que nuestra maquina no tiene las características adecuadas para el tipo de servicio que proporcionamos o por una mala administración nuestros recursos.

Configuración del servidor y/o plugins

Nota: Si no estas involucrado o interesado en administración de servidores Minecraft, esta parte podría ser algo compleja y aburrida, si este es tu caso solo ve un poco más abajo y encontrarás unos tips para mejorar el rendimiento del juego en tu ordenador.

En esta parte es donde pueden llegar los verdaderos dolores de cabeza cuando administramos un servidor, sin embargo estudiando un poco el tema ya no debería ser difícil identificar las posibles raíces del problema. Hay distintos métodos para prevenir el lag en nuestro servidor debido a la carga de TPS (Ticks por segundo) derivada de la configuración y/o carga de usuarios. Y de la misma manera hay métodos para identificar si es algún plugin el que genera el problema y también identificar fácilmente que plugin es el causante.

¿Qué son los ticks, los timings y para qué sirven?

Ticks

Los ticks son una unidad de medida y Minecraft funciona en ciclos y cada uno de estos ciclos se mide en ticks. Cada segundo ocurren 20 ticks y esto significa que un cada 50 milisegundos ocurre uno. Durante estos ticks ocurren distintos eventos y son procesados, estos incluyen todo lo que pasa desde la entrada y salida de usuarios al servidor hasta cada bloque que es colocado o removido y cada plugin instalado maneja los eventos de distinta manera, por ejemplo WorldGuard usaría el evento “PlayerMoveEvent” para asegurarse de que un usuario no este en un lugar en el que no debería. Y es aquí donde los datos proporcionados por el sistema de timings se hacen útiles.

Timings

Se le conoce como timings a un sistema de recopilación y entrega de datos sobre los tiempos que le toma a un servidor Minecraft para procesar los distintos eventos que ocurren en un cierto tiempo. Estos tiempos son medidos en ticks por segundo.

Los datos recopilados por este método te permiten monitorear cuanto tiempo le toma a cada plugin procesar los distintos eventos que ocurren en tu servidor. Y esto te permite saber cuál es la raíz de el lag ya que a un plugin que no está funcionando correctamente le tomaría más ticks para poder procesar los eventos lo que generaría un “delay” o retraso en el ciclo de los ticks disminuyendo el total adecuado de 20 TPS ó Ticks Por Segundo.

Y esto nos da pauta a más preguntas ¿Cómo obtener los timings? y ¿Cómo interpretarlos? Pero no te asustes, para obtenerlos únicamente necesitaremos 4 comandos, estos pueden ser ejecutados in game por un OP (O un usuario con el nodo de permisos bukkit.command.timings, que es recomendable asignar únicamente a administradores) o desde consola en el siguiente orden:

1.- /timings on ➠ Con este comando activaremos la recolección de datos y debe haber un lapso de tiempo considerable entre su ejecución y el siguiente comando, este tiempo puede variar ya que debemos esperar a que todos o al menos la mayoría de los plugins manejen los distintos eventos, también es recomendable que este activado durante el momento en el que disminuyen los tps del servidor y de igual manera no es recomendable que permanezca activo ya que genera carga extra e innecesaria al procesador.

2.- /timings report ➠ Este comando genera un reporte y lo guarda en el archivo /timings/timings.txt dentro de la carpeta en la que se almacena tu servidor, aunque no lo hace en el formato mas adecuado para su correcta interpretación y para obtener los resultados de forma más clara debemos usar el siguiente comando.

3.- /timings paste ➠ Con este comando se exportará el resultado de los timings a un sitio web en el que podrás leerlos en un formato más amigable y fácil de leer. Además de que regresará un mensaje con el link directo a tus resultados.

4.- /timings off ➠ Con este ultimo comando se detendrá el proceso de recolección de datos y es muy importante ejecutarlo ya que si no podríamos hacer que la búsqueda de una solución se convierta en parte del problema.

Ahora, el siguiente paso sería ir a la URL que se proporciona al usar el tercer comando y podremos leer nuestros resultados como en la siguiente imagen.

Los resultados usan un código de colores en el que entre mas alta es la carga el color puede ir de un anaranjado claro a un rojo intenso donde lo más alto será lo menos adecuado y podremos identificar si es un proceso de Minecraft o un plugin el que esta causando la disminución

Adicionalmente, podemos usar en distintos momentos del día el comando /tps que también puede ser ejecutado desde consola o in game (Por un OP o un usuario con el nodo de permisos bukkit.command.tps que se recomienda asignar únicamente a administradores) para saber cual es el estado actual de los TPS sin generar reporte. Y nos muestra los resultados en el siguiente formato:

Y a partir de los resultados podríamos determinar las medidas necesarias para reducir el lag si los procesos que están causando los problemas son parte de Minecraft podríamos probar modificando la configuración de nuestros archivos spigot.yml, bukkit.yml, y/o server.properties.

O si el problema es un plugin deberíamos considerar algunos factores como configuración o si el plugin en verdad es necesario y así decidir si podemos corregirlo, remplazarlo o sustituirlo.

Recomendaciones de configuración.

Antes de comenzar debo aclarar que estas son únicamente recomendaciones y no es obligatorio ajustarlas con los mismos valores, ni es necesario ajustar todos estos valores. Es recomendable analizar bien la situación para decidir que valores deben ser ajustados.

server.properties

En este archivo podríamos configurar el string llamado “network-compression-threshold”. Esta opción nos permite definir que tan grande o chico debe ser un paquete de datos entrante antes de que el servidor intente comprimirlo. Establecerlo en un punto más alto ayudara a liberar carga en el CPU pero aumentara el trafico de de datos y establecerlo con el valor -1 lo desactiva.

Cabe mencionar que si el servidor es parte de una network y el BungeeCord está en localhost o en el mismo datacenter (Con un ping entre ellos igual o menor a 2 ms) lo más recomendable seria deshabilitarlo estableciendo el valor en -1 ya que el BungeeCord estaría encargado de la compresión y mantenerlo habilitado representaría una carga innecesaria en el CPU, pero si el servidor esta corriendo de forma individual (Sin proxy) lo recomendable sería establecerlo en 512

Valor por defecto: 256

Recomendado en servidores sin proxy: 512

Recomendado estando detrás de bungeecord: -1

spigot.yml

En esta parte es en la que encontramos mas opciones o strings que nos pueden ayudar a reducir el lag. Acontinuación dejaré cada una con su nombre, el valor establecido por defecto y por ultimo el valor recomendado junto con una breve explicación de que es lo que hace cada una.

  • mob-spawn-range:

Esta opción define que tan lejos con referencia a los usuarios pueden spawnear los mobs sin importar si son hostiles o pasivos y con esto se reducirá la cantidad y frecuencia de spawneo pero sin que sea notorio que lo hemos hecho.

Valor por defecto: 4

Recomendado: 3

 

  • entity-activation-range:

Las entidades fuera de estos rangos recibirán ticks con una frecuencia menor.

Valor por defecto: animals: 32, monsters: 32, misc:16

Recomendado: animals: 16, monsters: 16, misc: 8

 

  • hopper-transfer, hopper-check y hopper-amount

Esto haría que las tolvas sean transfieran los ítems dentro de ellas 3 veces mas lento, pero lo harían 3 ítems a la vez, esto podría corromper algunos mecanismos basados en relojes que usen tolvas para marcar el tiempo, pero reduciría considerablemente el lag si es que las tolvas son las causantes.

Valor por defecto: transfer: 8, check: 8, amount: 1

Recomendado: transfer: 24, check: 24, amount: 3

 

  • max-entity-colisions:

Esta opción define cuantas veces puede colisionar una entidad por cada tick, esto no corrompe el comportamiento de las entidades pero ayuda mucho cuando el lag es provocado por granjas de mobs.

Valor por defecto: 8

Recomendado: 2 – 4 (Algún valor entre dos y cuatro)

 

  • merge-radius:

Aquí podemos definir el radio en el que las entidades tiradas en el suelo deberán agruparse y es definido en bloques por lo que si establecemos un radio de 3 los ítems dentro de un radio de 3 se agruparán

Valor por defecto: item: 2.5, exp: 3.0

Recomendado: item: 3.5, exp: 6.0

 

  • view-distance:

En este apartado podemos establecer cuantos chunks serían enviados a los jugadores para su renderizado, esto puede mejorar mucho el desempeño pero sacrificando la estética del servidor en usuarios que suelen usar una distancia de renderizado alta. No es recomendable fijarla en un valor menor a 3 ya que esto podría provocar que al arrojar, perlas de ender, ojos de ender y flechas estas caigan en un chunk descargado generando una perdida.

Valor por defecto: 10

Recomendado: 4 – 8 (Cualquier valor entre cuatro y ocho)

bukkit.yml

  • spawn-limits:

Esta opción es un poco más complicada de lo que parece, ya que no simplemente limita la cantidad de mobs. Entre mas usuarios tienes es menos seguro disminuir estos valores.

Valor por defecto: monsters: 70, animals: 15, water-animals: 5, ambient: 15

Recomendado: monsters: 50, animals: 10, water-animals: 3, ambient: 4

 

  • chunk-gc:

Esta opción nos permite descargar chunks innecesarios como aquellos que se encuentran fuera de la distancia de visión de los jugadores liberando carga en el CPU.

Valor por defecto: period-in-ticks: 600, load-threshold: 0

Recomendado: period-in-ticks: 300, load-threshold: 300

 

  • ticks-per.monster-spawns:

Aquí podemos establecer que tan seguido el servidor intentará spawnear un mob hostil y esto será en general para todo el servidor y no por cada usuario conectado. Entre mas alto sea el valor será menor la cantidad de mobs hostiles spawneando y no es recomendable establecerlo a mas de 2 a menos que el lag sea generado por el evento “mobSpawn” en cuyo caso el valor mas alto recomendado sería de 5.

Valor por defecto: 1

Recomendado: 2 – 5 (Cualquier valor entre dos y cinco tomando en cuenta la descripción)

Recomendaciones para disminuir el lag causado por el desempeño de nuestra pc.

Lamentablemente yo tengo poca o casi nada de experiencia con Minecraft PE o Better together o como quieran llamarlo XD por lo que mis recomendaciones se tendrán que limitar a la edición Java de Minecraft.

No siempre es necesario adquirir una computadora de mejores características (Y mayor costo porsupuesto), en algunas ocasiones con sólo hacer algunos ajustes en nuestro launcher y claro sin necesidad de instalar absolutamente nada, será suficiente para mejorar un poco o mucho nuestra experiencia de juego. Que tanto se noten estas mejoras ya dependería de muchos factores pero generalmente el cambio después de probar estas recomendaciones se nota al instante.

1.- Disminuir la distancia de renderizado disminuye notoriamente el lag ya que nuestra pc usará menos recursos gráficos y de procesador, aunque si disminuimos esta distancia demasiado podría afectar drásticamente la estética por lo que yo recomendaría mantener la distancia entre 6 y 8 chunks y esto lo configuraríamos abriendo Opciones > Gráficos > Renderizado

2.- Después justo abajo de donde encontramos la opción anterior podemos encontrar la opción “FPS máximos” esta lo mas recomendable es establecerla en su valor más alto que sería “sin limite” de igual manera encontraríamos este ajuste abriendo Opciones > Gráficos > FPS máximos y deslizando la barra hacia la derecha.

3.- Desactivar la iluminación suave, esta opción va a cambiar un poco el aspecto de el entorno pero mejora mucho el rendimiento en equipos de bajos recursos, para modificarlo debemos ir a Opciones > Gráficos > Iluminación Suave: No

4.- Las nubes, si bien estéticamente pueden ser atractivas la verdad es que no sirven para nada y no hacen mas que consumir recursos por lo que lo mas conveniente es desactivarlas por completo y esto lo hacemos nuevamente en Opciones > Gráficos > Capa de nubes: No

5.- Suavizado de mipmap, esto define la calidad de los gráficos mas alejados de nuestra ubicación y esto mismo genera un consumo mas alto de recursos sin una utilidad alta por defecto viene con un valor establecido de 4 y bajándolo a 1 se notara un cambio importante, esta opción la encontramos en Opciones > Gráficos > Suavizado de mipmap: 1

6.- Partículas, aunque en lo personal a mi me parecen muy bonitas no es lo mejor para todos los equipos ya que pueden generar caídas de FPS, entre más partículas menos FPS, si todas las opciones anteriores no te han mejorado el rendimiento al grado que necesitas lo mejor sería desactivarlas por completo y esto lo puedes hacer en Opciones > Gráficos > Partículas: Ninguna

7.- Sombras de entidades, esta opción lo único que haces es poner una sobra casi imperceptible debajo de cada entidad, sin embargo aunque no es muy notoria sigue consumiendo recursos y desactivarlo nos ayudaría a optimizar el rendimiento y la encontramos en Opciones > Gráficos > Sombras de entidades: No

8.- Por ultimo y más importante el VBOs, esta opción afecta cuestiones muy técnicas a nivel de gráficos pero esta es una de las opciones que mejoran más el rendimiento y el cambio se nota de inmediato ya que es grande, lo mejor es mantenerlo siempre desactivado y una vez mas lo podemos encontrar en Opciones > Gráficos > VBOs: No

Por último solo me queda desear que estás recomendaciones te sean útiles y recordarte que si algo no te quedó muy claro, necesitas ayuda o conoces algo que haya dejado fuera de este artículo no dudes en dejar un comentario en la parte de abajo o contactar directamente conmigo a través de Twitter @BitlandCraft