Requisitos de Hardware y Red Para Servidores del Motor Source

El Source engine es un motor de videojuegos 3D desarrollado por Valve. El Source engine es conocido por sus avances en física, IA y gráficos que hicieron que los juegos fueran realistas para su época, mientras se mantenían escalables en hardware más antiguo y menos potente. Los servidores del Source engine son servicios de juego hospedados que permiten a los jugadores conectarse y jugar juntos en el mundo del servidor. Los servidores en el Source engine pueden personalizarse con mods que resultan en una experiencia de juego única y muchas veces divertida para todos los jugadores conectados al servidor.

Los juegos que corren sobre el Source engine incluyen Team Fortress 2, Counter-Strike: Source, Garry's Mod, ¡y muchos otros!

Una pregunta común es cuáles son los requisitos de hardware y red para correr un servidor de Source engine, junto con cómo se compara con servidores en otros juegos como Minecraft y Rust. La respuesta a esta pregunta es que realmente depende.

Si bien los servidores de Source engine son mucho más ligeros en uso de RAM en comparación con otros juegos como Minecraft y Rust, son mayormente single-threaded. Esto significa que tener un procesador con un bajo número de núcleos, pero alto rendimiento single-thread, va a rendir mejor que un procesador con muchos núcleos, pero bajo rendimiento single-thread, para servidores de Source engine. Esto es especialmente cierto si planeas hospedar un modo de juego intensivo o quieres tener muchos jugadores conectados al servidor al mismo tiempo.

Dicho esto, aquí hay una lista de factores adicionales a considerar al decidir tus requisitos de hardware y red.

• La cantidad máxima de jugadores que el servidor tendrá conectados y jugando al mismo tiempo.
• El modo de juego, la cantidad de mods, y el tipo de mapas que corre el servidor.
• El tickrate del servidor.
• Los valores de ConVar relacionados al rendimiento del servidor.

Si quieres el mejor rendimiento absoluto y tienes el dinero, personalmente sugeriría buscar un servidor que contenga una CPU de una lista como los benchmarks de CPU con mejor puntuación en rendimiento single-thread de Passmark.

Jugadores Concurrentes

Cuantos más jugadores estén conectados al servidor al mismo tiempo, más datos de red se intercambian entre cada cliente y, típicamente, más cosas suceden en el juego y en el servidor mismo, resultando en un mayor uso de CPU.

Si bien no hay una guía general o regla de oro sobre velocidades single-thread y cantidad de jugadores debido a que hay muchas otras variables, si planeas tener muchos jugadores conectados al servidor a la vez, deberías intentar adquirir una CPU más moderna con mayor rendimiento single-thread.

Modo De Juego, Cantidad De Mods, Y Tipos De Mapas

Estos son factores muy importantes a considerar al decidir qué requisitos de servidor necesitas. Por ejemplo, un servidor corriendo un modo de juego como Deathmatch en Counter-Strike: Source, donde los jugadores están constantemente disparándose entre sí, reapareciendo y corriendo por todas partes, muy probablemente va a consumir más recursos que un servidor corriendo un modo de juego donde, cuando los usuarios mueren, no reaparecen hasta la siguiente ronda.

Dicho esto, los mapas de espacios cerrados o mapas que usan muchos props físicos muy probablemente van a consumir más poder de CPU que un mapa más grande y abierto.

El Tickrate Del Servidor

El tickrate es la frecuencia con la que el servidor simula el juego. Por defecto, el tickrate de un servidor está establecido en 66.66... (cada 15ms). Este valor puede cambiarse usando el argumento de línea de comandos -tickrate en el comando de inicio del servidor, si el juego o un mod permite a los administradores del servidor cambiarlo.

Cuanto más alto sea el tickrate del servidor, más poder de CPU y ancho de banda se requiere. Esto también resulta en que el servidor envíe y reciba más actualizaciones hacia y desde los clientes, lo cual mejora la latencia del cliente, el registro de impactos (hit registration), ¡y más!

Hay muchos servidores en Garry's Mod que hospedan hasta 128 jugadores conectados a la vez. Logran esto porque corren un valor de tickrate bajo, como 33 o 22, que es lo suficientemente bajo para que la CPU maneje la carga general del servidor en la mayoría de los casos (dependiendo del servidor, por supuesto).

Los Valores De ConVar De Rendimiento Del Servidor

Hay algunos ConVars relacionados al rendimiento del servidor que puedes modificar en el servidor y que impactan cuánta CPU y ancho de banda consume tu servidor. Dicho esto, estas configuraciones pueden impactar la latencia del cliente, el número de paquetes perdidos, el choke, y más.

Aquí hay una lista de algunos ConVars relacionados al rendimiento que he encontrado ser los más beneficiosos.

• sv_maxrate - La tasa máxima de ancho de banda permitida al cliente (tanto entrante como saliente) por segundo en el servidor, en "bytes". Establecer esto en 0 indica ilimitado y es recomendado si tienes la capacidad de red y hardware necesaria.
• sv_minrate - La tasa mínima de ancho de banda permitida al cliente (tanto entrante como saliente) por segundo en el servidor, en "bytes".
• sv_maxupdaterate - La cantidad máxima de paquetes de actualización por segundo que el servidor puede enviar a un cliente. Esto normalmente es igual al valor del tickrate de tu servidor. Sin embargo, en algunos casos se puede reducir para disminuir la carga en la CPU o el uso de ancho de banda.
• sv_minupdaterate - La cantidad mínima de paquetes de actualización por segundo que el servidor puede enviar al cliente. Esto normalmente va desde 0 hasta la mitad del valor del tickrate de tu servidor (por ejemplo, 33).
• sv_maxcmdrate - La cantidad máxima de paquetes de comando por segundo que el servidor puede enviar al cliente. Esto normalmente es igual al valor del tickrate de tu servidor. Sin embargo, en algunos casos se puede reducir para disminuir la carga en la CPU o el uso de ancho de banda.
• sv_mincmdrate - La cantidad mínima de paquetes de comando por segundo que el servidor puede enviar al cliente. Esto normalmente va desde 0 hasta la mitad del valor del tickrate de tu servidor (por ejemplo, 33).
• net_splitpacket_maxrate - La cantidad máxima de bytes por segundo que el servidor puede enviar en paquetes divididos al cliente. Establecer esto en un valor más alto, como 128000, puede ayudar en situaciones donde ocurre choke debido a mucha transmisión de datos de red a la vez.
• net_maxcleartime - La cantidad máxima de tiempo en segundos que el servidor dedicará a procesar y enviar datos de red en un solo tick. Establecer esto en un valor bajo como 0.001 puede reducir el choke en ciertas situaciones, pero requerirá más potencia de CPU.
• sv_parallel_sendsnapshot - Cuando está en 1, permitirá que el servidor use un hilo separado para preparar las capturas del estado del juego (snapshots) para cada cliente. Esto puede mejorar mucho el rendimiento del servidor en entornos con muchos jugadores.

Te recomiendo leer sobre Source Multiplayer Networking para entender mejor en qué valores deberías configurar esto. ¡También encontré este tema de NFOservers.com extremadamente informativo y útil!

Si estás usando un proveedor de hosting dedicado, lo más probable es que tengas la capacidad de red para configurar estos valores de ConVar en valores altos/ilimitados. En este caso, los siguientes valores deberían funcionar en la mayoría de los casos.

sv_maxrate 0
sv_minrate 75000
sv_maxupdaterate 66
sv_minupdaterate 20
sv_maxcmdrate 66
sv_mincmdrate 20
net_splitpacket_maxrate 128000
net_maxcleartime 0.001
sv_parallel_sendsnapshot 1

Si aún no estás seguro de qué valores deberías configurar en estos ConVars relacionados con el rendimiento, te recomiendo usar una herramienta como esta para calcular los valores. Dicho esto, se recomienda que hagas una prueba de velocidad de red usando herramientas como SpeedTest.net o CloudFlare para obtener las velocidades de subida y bajada de la red de tu servidor. Estas velocidades de red juegan un papel importante en cuántos jugadores puedes tener conectados al servidor al mismo tiempo antes de tener problemas relacionados con la red, como pérdida de paquetes, entre otros (especialmente tu velocidad de subida, ya que esto indica la cantidad de ancho de banda que puedes enviar a todos los jugadores a la vez a través de Internet).

Monitoreando el Rendimiento del Servidor

La mejor herramienta dentro del juego para monitorear el rendimiento del servidor en juegos con motor Source es el Net Graph incorporado. Puedes mostrar el net graph ajustando el valor de net_graph en la consola de desarrollador de 0 a 4.

Esta herramienta muestra la cantidad de ancho de banda que estás enviando y recibiendo desde el servidor al que estás conectado, el FPS del servidor, la cantidad de actualizaciones que tú y el servidor están enviando/recibiendo, ¡y más!

Una explicación más detallada del Net Graph se puede encontrar aquí.

Aquí hay algo de información de la página de la Wiki enlazada anteriormente:

Área 1

Esta área es la leyenda de los colores usados en la sección de payload del gráfico. Si una parte del payload llega pero no encaja en ninguno de los rangos predeterminados, se representa en el área clara entre el último color y el pequeño punto blanco que representa el tamaño completo del paquete (ver indicador a en la imagen)

Área 2

Para paquetes mayores a 300 bytes que estén en el percentil 95, el tamaño del paquete se muestra en texto en la parte superior del área de payload (ver marcador 2). Nótese que la tecnología Orange Box usa compresión en los paquetes, pero los tamaños reportados en el payload de net_graph se basan en el tamaño del payload descomprimido.

Área 3

El FPS de la conexión local y el ping de ida y vuelta al servidor se muestran en el área 3.

Área 4

Esta área muestra el uso actual de ancho de banda. El in/out muestra el tamaño en bytes del último paquete entrante y saliente. El k/s muestra los kilobytes por segundo (promedio móvil) vistos recientemente en cada dirección.

Área 5

Esta área muestra el rendimiento del servidor al que el cliente está conectado. La etiqueta sv muestra el FPS del servidor según la última actualización de red entregada al cliente. El var muestra la desviación estándar del frametime del servidor (donde server fps = 1.0 / frametime) durante los últimos 50 frames registrados por el servidor. Si el framerate del servidor está por debajo de 20 fps, esta línea se dibujará en amarillo. Si está por debajo de 10 fps, se dibujará en rojo.

Área 6

El indicador lerp muestra la cantidad de milisegundos de interpolación que está usando el cliente. Algunas notas sobre el valor de lerp se detallan a continuación.

Area 7

Esta área muestra el valor actual de cl_updaterate del usuario, la cantidad real de actualizaciones por segundo recibidas del servidor, la cantidad real de paquetes por segundo enviados al servidor y el valor cl_cmdrate del usuario (que es la cantidad deseada de paquetes por segundo que el usuario quiere enviar al servidor).

Area 8

Cuando net_graphshowlatency está en 1, esta área muestra una vista histórica de la latencia de la conexión. La altura (indicada por el marcador d) corresponde al tiempo de net_graphmsecs (en realidad hay un poco de margen después de net_graphmsecs en la parte superior para que entren los campos de texto). Las líneas verticales rojas indican paquetes perdidos desde el servidor hasta el cliente. Si el gráfico muestra un marcador amarillo (como en el marcador c), esto indica que el servidor tuvo que retener uno o más paquetes antes de enviar una actualización al cliente.

Area 9

Cuando net_graphshowinterp está en 1, esta área muestra para cada fotograma del cliente cuánta interpolación fue necesaria. Si hay una brecha grande entre paquetes (pérdida de paquetes, framerate del servidor demasiado bajo, etc.), entonces el cliente tendrá datos insuficientes para interpolar y comenzará a extrapolar. La extrapolación se muestra como barras naranjas que se elevan por encima de la línea blanca (se puede ver una racha de extrapolación justo a la izquierda del marcador 9). Además, el píxel más bajo indica si se envió un paquete CUserCmd (usercmd) en ese fotograma de renderizado, o si fue retenido por el cliente y agregado debido al valor cl_cmdrate del usuario.

Dedicated Hosting VS LAN Server

Aunque puedes alojar un servidor público en tu red doméstica (LAN), no se recomienda. En su lugar, deberías comprar un servidor a un proveedor de hosting dedicado.

Si bien la tarifa de suscripción que suele venir con el hosting dedicado a menudo se considera una gran desventaja, las razones para usar hosting dedicado incluyen:

• Mejor protección contra ataques (D)DoS debido a una mayor capacidad de red y sistemas de mitigación diseñados específicamente para manejar ataques.
• Mejor enrutamiento de clientes y latencia.
• Mayor estabilidad (por ejemplo, si ocurre un corte de luz en casa, el servidor no se cae).

Además, aquí hay un par de razones para no alojar tu servidor en casa.

• Algunos ISP están en contra de alojar un servidor de juego público en tu red doméstica.
• Mayores costos de electricidad y ancho de banda de red en casa, dependiendo de cuántos servidores se ejecuten, la carga del servidor, el procesador del servidor, etc.

See Also

• NFOservers - Guía de solución de problemas de lag en juegos de Valve
• Valve - Source Multiplayer Networking
• Source Dedicated Server Rate Calculator 2015
• Valve - TF2 Net Graph

https://moddingcommunity.com/blog/how-to-download-run-steamcmd/

Conclusion

Con esto concluye esta guía/tema de la base de conocimientos. A estas alturas, deberías tener una mejor comprensión de qué hardware y red necesitas al ejecutar un servidor de Source engine.

Si tienes alguna pregunta o comentario sobre esta guía, por favor responde en su tema del foro aquí! Esta guía se seguirá trabajando y mejorando con el tiempo.

¡Únete a nuestro servidor de Discord!