Requisitos de Hardware e Rede Para Servidores de Source Engine

O Source engine é um motor de jogo 3D desenvolvido pela Valve. O Source engine é bem conhecido por seus avanços em física, IA e gráficos que tornaram os jogos realistas para a sua época, ao mesmo tempo em que era escalável em hardware mais antigo e menos potente. Servidores do Source engine são serviços de jogo hospedados que permitem que jogadores se conectem e joguem juntos no mundo do servidor. Servidores no Source engine podem ser personalizados com mods que resultam em uma experiência de jogo única e muitas vezes divertida para todos os jogadores conectados ao servidor.

Jogos que rodam no Source engine incluem Team Fortress 2, Counter-Strike: Source, Garry's Mod, e muitos outros!

Uma pergunta comum é quais são os requisitos de hardware e rede para rodar um servidor Source engine, além de como isso se compara a servidores de outros jogos como Minecraft e Rust. A resposta para essa pergunta é: depende muito.

Embora servidores Source engine sejam muito mais leves em uso de RAM comparados a outros jogos como Minecraft e Rust, eles são majoritariamente single-threaded. Isso significa que ter um processador com poucos núcleos, mas alto desempenho single-thread, vai performar melhor do que um processador com muitos núcleos, mas baixo desempenho single-thread, para servidores Source engine. Isso é especialmente verdade se você planeja hospedar um modo de jogo intenso ou quer ter muitos jogadores conectados ao servidor ao mesmo tempo.

Dito isso, aqui está uma lista de fatores adicionais a considerar ao decidir seus requisitos de hardware e rede.

• A quantidade máxima de jogadores que o servidor terá conectados e jogando ao mesmo tempo.
• O modo de jogo, quantidade de mods e o tipo de mapas que o servidor roda.
• O tickrate do servidor.
• Os valores de ConVar relacionados a desempenho do servidor.

Se você quer o melhor desempenho absoluto e tem o dinheiro, eu pessoalmente sugeriria procurar um servidor que contenha uma CPU de uma lista como os benchmarks de CPU mais bem avaliados para desempenho single-thread do Passmark.

Jogadores Simultâneos

Quanto mais jogadores conectados ao servidor ao mesmo tempo, mais dados de rede são trocados entre cada cliente e, tipicamente, mais coisas acontecem no jogo e no próprio servidor, resultando em maior uso de CPU.

Embora não haja uma diretriz geral ou regra prática sobre velocidades single-thread e quantidade de jogadores, já que há tantas outras variáveis, se você planeja ter muitos jogadores conectados ao servidor ao mesmo tempo, você deveria tentar adquirir uma CPU mais moderna com maior desempenho single-thread.

Modo de Jogo, Quantidade de Mods e Tipos de Mapas

Esses são fatores muito importantes a considerar ao decidir quais requisitos de servidor você precisa. Por exemplo, um servidor rodando um modo de jogo como Deathmatch em Counter-Strike: Source, onde jogadores estão constantemente atirando um no outro, reaparecendo e correndo por aí, provavelmente vai consumir mais recursos do que um servidor rodando um modo de jogo onde, quando os usuários morrem, eles não reaparecem até a próxima rodada.

Dito isso, mapas de combate próximo ou mapas que usam muitos props físicos provavelmente vão consumir mais poder de CPU do que um mapa maior e mais aberto.

O Tickrate do Servidor

O tickrate é a frequência com que o servidor simula o jogo. Por padrão, o tickrate de um servidor é definido como 66.66... (a cada 15ms). Esse valor pode ser alterado usando o argumento de linha de comando -tickrate no comando de inicialização do servidor, se o jogo ou um mod permitir que administradores do servidor o alterem.

Quanto maior o tickrate do servidor, mais poder de CPU e largura de banda são necessários. Isso também resulta no servidor enviando e recebendo mais atualizações para e dos clientes, o que melhora a latência do cliente, o registro de acertos (hit registration) e mais!

Existem muitos servidores em Garry's Mod que hospedam até 128 jogadores conectados ao mesmo tempo. Eles conseguem alcançar isso porque rodam com um valor de tickrate baixo, como 33 ou 22, o que é baixo o suficiente para a CPU lidar com a carga geral do servidor na maioria dos casos (dependendo do servidor, claro).

Os Valores de ConVar de Taxa de Desempenho do Servidor

Existem algumas ConVars relacionadas ao desempenho do servidor que você pode modificar no servidor e que impactam quanto de CPU e largura de banda seu servidor consome. Dito isso, essas configurações podem impactar a latência do cliente, a contagem de perda de pacotes, o choke e mais.

Aqui está uma lista de algumas ConVars relacionadas a desempenho que considero as mais benéficas.

• sv_maxrate - A taxa máxima de largura de banda permitida ao cliente (tanto entrada quanto saída) por segundo no servidor, em "bytes". Definir isso para 0 indica ilimitado e é recomendado se você tiver capacidade de rede e hardware suficiente.
• sv_minrate - A taxa mínima de largura de banda permitida ao cliente (tanto entrada quanto saída) por segundo no servidor, em "bytes".
• sv_maxupdaterate - A quantidade máxima de pacotes de update por segundo que o servidor pode enviar a um cliente. Isso geralmente é igual ao valor de tickrate do seu servidor. No entanto, em alguns casos pode ser reduzido para diminuir a carga na CPU ou o uso de largura de banda.
• sv_minupdaterate - A quantidade mínima de pacotes de update por segundo que o servidor pode enviar ao cliente. Isso geralmente varia de 0 até a metade do valor de tickrate do seu servidor (por exemplo, 33).
• sv_maxcmdrate - A quantidade máxima de pacotes de comando por segundo que o servidor pode enviar ao cliente. Isso geralmente é igual ao valor de tickrate do seu servidor. No entanto, em alguns casos pode ser reduzido para diminuir a carga na CPU ou o uso de largura de banda.
• sv_mincmdrate - A quantidade mínima de pacotes de comando por segundo que o servidor pode enviar ao cliente. Isso geralmente varia de 0 até a metade do valor de tickrate do seu servidor (por exemplo, 33).
• net_splitpacket_maxrate - A quantidade máxima de bytes por segundo que o servidor pode enviar em pacotes divididos (split packets) ao cliente. Definir isso para um valor mais alto, como 128000, pode ajudar em situações onde ocorre choke com muitos dados de rede sendo transmitidos ao mesmo tempo.
• net_maxcleartime - A quantidade máxima de tempo, em segundos, que o servidor gastará processando e enviando dados de rede em um único tick. Definir isso para um valor baixo, como 0.001, pode reduzir o choke em certas situações, mas exigirá mais poder de CPU.
• sv_parallel_sendsnapshot - Quando definido como 1, permite que o servidor use uma thread separada para preparar os snapshots do estado do jogo para cada cliente. Isso pode melhorar bastante o desempenho do servidor em ambientes com muitos jogadores.

Eu recomendo ler sobre Source Multiplayer Networking para entender melhor quais valores esses parâmetros devem ter. Também achei este tópico do NFOservers.com extremamente informativo e útil!

Se você está usando um provedor de hospedagem dedicada, muito provavelmente terá a capacidade de rede necessária para definir esses valores de ConVar como altos/ilimitados. Nesse caso, os seguintes valores devem funcionar na maioria dos 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

Se você ainda não tem certeza de quais valores definir para essas ConVars relacionadas a desempenho, recomendo usar uma ferramenta como esta para calcular os valores. Além disso, é recomendado que você faça um teste de velocidade de rede usando ferramentas como SpeedTest.net ou CloudFlare para obter as velocidades de upload e download da rede do seu servidor. Essas velocidades de rede têm um papel importante em quantos jogadores você pode ter conectados ao servidor simultaneamente antes de enfrentar problemas relacionados à rede, como perda de pacotes e assim por diante (especialmente sua velocidade de upload, já que ela indica a quantidade de largura de banda que você pode enviar a todos os jogadores ao mesmo tempo pela Internet).

Monitoramento de Desempenho do Servidor

A melhor ferramenta dentro do jogo para monitorar o desempenho do servidor em jogos com o Source engine é o Net Graph embutido. Você pode exibir o net graph ajustando o valor de net_graph no console de desenvolvedor de 0 para 4.

Essa ferramenta exibe a quantidade de largura de banda que você está enviando e recebendo do servidor ao qual está conectado, o FPS do servidor, a quantidade de updates que você e o servidor estão enviando/recebendo, e muito mais!

Uma explicação mais detalhada do Net Graph pode ser encontrada aqui.

Aqui estão algumas informações da página da Wiki mencionada anteriormente:

Área 1

Essa área é a legenda para as cores usadas na seção de payload do gráfico. Se parte do payload chega mas não se encaixa em nenhum dos intervalos predeterminados, ela é representada na área clara entre a última cor e o pequeno ponto branco que representa o tamanho total do pacote (veja o indicador a na imagem)

Área 2

Para pacotes maiores que 300 bytes que estão no percentil 95, o tamanho do pacote é exibido em texto no topo da área de payload (veja o marcador 2). Observe que a tecnologia Orange Box usa compressão nos pacotes, mas os tamanhos reportados no payload do net_graph são baseados no tamanho do payload descomprimido.

Área 3

O FPS da conexão local e o ping de ida e volta até o servidor são mostrados na área 3.

Área 4

Essa área mostra o uso atual de largura de banda. O in/out mostra o tamanho em bytes do último pacote recebido e enviado. O k/s mostra os kilobytes por segundo (média móvel) vistos recentemente em cada direção.

Área 5

Essa área mostra o desempenho do servidor ao qual o cliente está conectado. A tag sv mostra o FPS do servidor de acordo com a última atualização de rede entregue ao cliente. O var mostra o desvio padrão do frametime do servidor (onde server fps = 1.0 / frametime) ao longo dos últimos 50 quadros registrados pelo servidor. Se o framerate do servidor estiver abaixo de 20 fps, essa linha será desenhada em amarelo. Se estiver abaixo de 10 fps, essa linha será desenhada em vermelho.

Área 6

O indicador lerp mostra o número de milissegundos de interpolação sendo usados pelo cliente. Algumas observações sobre o valor de lerp seguem abaixo.

Area 7

Esta área mostra a configuração atual de cl_updaterate do usuário, o número real de atualizações por segundo efetivamente recebidas do servidor, o número real de pacotes por segundo enviados ao servidor e a configuração cl_cmdrate do usuário (que é o número desejado de pacotes por segundo a serem enviados ao servidor).

Area 8

Quando net_graphshowlatency está definido como 1, esta área mostra uma visão histórica da latência da conexão. A altura (indicada pelo marcador d) corresponde ao tempo net_graphmsecs (na verdade, há uma pequena margem extra após o net_graphmsecs no topo para caber os campos de texto). Linhas verticais vermelhas indicam pacotes perdidos do servidor até o cliente. Se o gráfico mostrar um marcador amarelo (como no marcador c), isso indica que o servidor teve que segurar um ou mais pacotes antes de enviar uma atualização ao cliente.

Area 9

Quando net_graphshowinterp está definido como 1, esta área mostra, para cada frame do cliente, quanta interpolação foi necessária. Se houver um grande intervalo entre pacotes (perda de pacotes, taxa de frames do servidor muito baixa, etc.), o cliente terá dados insuficientes para interpolação e começará a extrapolar. A extrapolação é mostrada como barras laranjas que sobem acima da linha branca (uma sequência de extrapolação pode ser vista logo à esquerda do marcador 9). Além disso, o pixel na parte inferior indica se um pacote CUserCmd (usercmd) foi enviado naquele frame de renderização, ou retido pelo cliente e agregado devido à configuração cl_cmdrate do usuário.

Dedicated Hosting VS LAN Server

Embora você possa hospedar um servidor público na sua rede doméstica (LAN), isso não é recomendado. Em vez disso, você deveria comprar um servidor de um provedor de hospedagem dedicada.

Embora a taxa de assinatura que geralmente acompanha a hospedagem dedicada seja frequentemente considerada um grande contra, razões para usar hospedagem dedicada incluem:

• Melhor proteção contra ataques (D)DoS devido à maior capacidade de rede e sistemas de mitigação especificamente projetados para lidar com ataques.
• Melhor roteamento de clientes e latência.
• Mais estabilidade (por exemplo, se ocorrer uma queda de energia em casa, o servidor não sairá do ar).

Além disso, aqui estão alguns motivos para não hospedar seu servidor em casa.

• Alguns provedores de internet (ISPs) são contra a hospedagem de um servidor de jogo público na sua rede doméstica.
• Custos mais altos de energia elétrica e de banda de rede em casa, dependendo de quantos servidores são executados, da carga do servidor, do processador do servidor, etc.

See Also

• NFOservers - Guia de solução de problemas de lag em jogos da 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

Com isso, concluímos este guia/tópico de base de conhecimento. Agora você já deve ter uma melhor compreensão do hardware e da rede necessários para rodar um servidor de Source engine.

Se você tiver alguma dúvida ou feedback sobre este guia, por favor responda ao seu tópico no fórum aqui! Este guia será trabalhado e aprimorado ao longo do tempo.

Participe do nosso servidor do Discord!