- Nhaca escreveu:
- Bem, em princípio, nossos servidores estão sim com updaterate 24, mas isso não afeta no desempenho, ao contrário, ajuda a minimizar possíveis travamentos (ou mesmo lags) durante o início das partidas. Lembre-se que o MIC é muito utilizado nesse início e também quando o servidor está lotado, é melhor garantir a estabilidade. Ok? Até mais.
Desculpe mas vou descordar mais uma vez.
Veja oque o tutorial diz:
Esta é uma breve descrição de como os Servidores e Clientes interagem, FPS, Optimizadores de Latência (FPS) e como todas as partes trabalham juntas.
O Motor de Jogo do Multi-jogador Half-Life é composto por um Servidor e um ou mais Clientes, que estão a comunicar interativamente a semi-tempo-real através da internet. A comunicação entre o Servidor e os Clientes usa o protocolo UDP que é muito adequado a este tipo de comunicação. <mais informação sobre TCP/UDP abaixo>
O Servidor é uma máquina de geração sem quaisquer gráficos. O Cliente é uma máquina (o computador) de geração com sub-sistemas gráficos e acústicos que está a interagir também com o jogador através do teclado, rato, joystick, seja o que for que o jogador use.
Normalmente, o Servidor corre a um ciclo de geração, por defeito, de 100FPS (Frames Por Segundo) ou 10ms por frame. Com várias inovações intencionais e acidentais disponíveis, o Servidor pode ser corrido a ciclos muito mais rápidos, até a um máximo de 1000FPS. Existem alguns limites do hardware e do sistema operativo que determinam o máximo de FPS que um servidor pode alcançar.
executar o servidor a 500FPS ou 1000FPS não havera nenhum impacto direto nos FPSs dos computadores dos clientes, cada computador gera os frames independentemente. A taxa de FPS do Servidor é ajustado através do comando sys_ticrate (mínimo 0, máximo 1000).
Se o computador no qual o Servidor está sendo executado tiver o "horsepower" disponível, usar valores altos de FPS (até um máximo de 1000) irão ocorrer várias melhorias. Vamos ver o que ira acontecer aqui e porque é que isto acontece.
O servidor está executando um mapa, a armazenar recursos, a gerar frames, a receber atualizações de estado dos clientes e a enviar atualizações para os clientes.
O cliente está executando o mesmo mapa (os "checksums" têm de corresponder), a gerar os seus próprios frames, a enviar atualizações e a receber atualizações do servidor. O cliente está também exibindo, gráfica e acusticamente, os frames (o servidor não o faz) e interatuando com o jogador.
Mais ainda, o cliente gera todas as animações e posições dos modelos, sprites, sons, texturas animadas (como a água) e entidades móveis no campo de visão do jogador. Isto inclui armas e tiros em vôo.
O servidor guarda o registo de tudo isto mas não tem de gerar nada para eles, apenas atualizar o cliente acerca de mudanças posicionais e eventos.
Então nós vemos que existem dois sistemas de geração diferentes e independentes (e ainda assim dependentes) que estão comunicando reciprocamente.
Digamos que o Servidor está gerando frames a 500FPS. Isso significa que uma captura instantânea de tudo o que acontece está disponível para ser enviada ao cliente cada 2 milisegundos (1000FPS á cada 1ms).
O cliente está no fundo a interatuar de duas maneiras diferentes com o servidor. O cliente envia atualizações da sua posição e ações 30 vezes por segundo (o cl_cmdrate por defeito é 30) e envia um pedido para uma atualização completa pelo servidor 20 vezes por segundo (o cl_updaterate por defeito é 20). Por agora iremos ignorar o cl_cmdrate sendo que não precisa de uma resposta de dados a partir do servidor.
Então com um cl_updaterate de 20 isso significa que cada 50ms aproximadamente o cliente irá requerer uma atualização a partir do servidor. Então adicionamos o tempo de trânsito (1/2 latência) do cliente para o servidor e depois haverá (com o servidor a gerar 500FPS) no máximo um atraso de 2ms antes dessa atualização ser gerada e enviada de volta ao cliente com o atraso adicional de 1/2 latência.
A 100FPS, existe um máximo de 10ms de atraso para isto acontecer.
Agora como todos os clientes estão gerarando e requererendo atualizações independentemente, cada um aleatoriamente (a cada um dos outros) irá enviar estas atualizações ao servidor, então pense nisto como uma “tempestade” de pedidos de atualizações todas a chegar a diferentes tempos ao servidor.
A taxa a que estas actualizações são enviadas reciprocamente são controladas pelo comando “rate” no caso do cliente (a a 20000 máximo) e sv_minrate e sv_maxrate no caso do Servidor. As configurações do Servidor sobrepõem-se às do Cliente. A taxa é medida em bytes por segundo. Em média, um jogador com uma taxa de 7500 envia e recebe um máximo de cerca de 7.5Kbytes por segundo para/do servidor.
Se o servidor está sendo executado a 100FPS então existe um periodo de 10ms para estes pedidos se acumularem enquanto o servidor gera os dados e então envia as atualizações para todos os clientes na fila atual. Se o Servidor está apto a gerar o frame atual antes do fim do intervalo do sys_tickrate ele efetivamente “descansará” o resto do tempo.
Isto significa que se existirem vários clientes, o servidor terá de enviar uma grande quantidade de dados cada 10ms que poderá forçar a ligação com o servidor.
Se o servidor está sendo executado a 1000FPS, então efetivamente assim que cada cliente envia um pedido de atualização, o servidor pode então fornecer a atualização para aquele cliente apenas, quase imediatamente o que resulta em muitos fluxos de dados mais pequenos e distribuídos através da ligação com o servidor (a média total é contudo a mesma).
Isto efetivamente faz três coisas, diminui os pedidos na ligação (podendo ter menos “congestionamento”), diminui ligeiramente o aumento relativo de latência que cada cliente vê (de 10ms a 1 ou 2 ms) e mais importante, mantém o cliente ligeiramente mais atualizado enquanto o que está acontecendo, o que melhora a pontaria e diminui o lag.
(Nota: o servidor pode enviar o atual frame pré-gerado assim que ele receber um pedido do cliente e não esperar pelo próximo frame. Eu não tenho conseguido verificar isto de outra maneira senão empiricamente e a maneira como estou descrevendo-o é como parece comportar-se funcionalmente).
Em resumo:
1. O Servidor está gerando frames a 100FPS ou 500FPS ou 1000FPS, atualizações estão disponíveis cada 10ms ou 2ms ou 1ms. Os clientes estão gerando frames a (por defeito) 100FPS e a visualizar frames a (habitualmente) 30 a 100 FPS dependendo do CPU e do hardware gráfico que têm e do que está acontecendo no mapa.
2. Os Clientes estão enviando informações de atualização (cl_updaterate) ao servidor a (por defeito) 30 vezes por segundo.
3. Os Clientes estão solicitando atualizações a partir do servidor (cl_cmdrate) a (por defeito) 20 vezes por segundo (que é 50ms entre as atualizações). O Servidor está enviando informações de atualização ao cliente. Curante esse intervalo de 50ms (e o tempo de viagem da latência), o cliente está gerando frames visíveis, prevendo eventos e a interatuar com o jogador até a atualização for recebida.
4. Os Clientes enviam dados ao Servidor e o Servidor envia dados ao Cliente a uma taxa definida pelo cliente, o qual está limitado pelo comando do servidor sv_maxrate.
5. Os Servidores executando FPSs mais elevados estarão aptos a enviar informações de atualização ao cliente mais rapidamente e a diminuir ligeiramente o “congestionamento” na ligação com o servidor.
6. Os Clientes irão enviar ao servidor e receber do Servidor a mesma quantidade de dados não importando os FPS a que o servidor está sendo executado. Isto com certeza assume que o servidor tem limites razoáveis definidos (sv_maxupdaterate).
7. Os commandos do Servidor sv_maxrate e sv_maxupdaterate têm um efeito imediato, poderá haver um ligeiro atraso antes das mudanças serem visíveis (se existe algum efeito visível a ser notado).
cl_updaterate is the number of game packets per second the
client will attempt to request off the server. This should be no higher than 100 or the maximum number of frames per second you are getting, and should be no lower than 20.
Fonte: http://supportwiki.steampowered.com/wiki/Gold_Source_Engine:pt
************************************************
Cara o minimo recomendado é 20. Concordo que no Brasil as conexões são muito fracas. Eu tenho um speedy 8mb o up dele chega a 85k, se vc aumentar a taixa de UP não vai piorar o SV por as conexões mais baixas (Ate o 2mb) tem upload de 17k +ou-.
Claro que o mic em excesso acaba com tudo, ele faz com que o topo (25k) caia para 11k no inicio do round, se vcs deixarem 35 vai cair para 21k. Vc vai ver como ficará bem melhor, faz o teste que vc verá a diferença.
Qua Jul 25, 2007 9:30 am
![[Fþ§ Games]™ PUDIM](https://2img.net/i/fa/i/avatars/gallery/Cinema_h/Cinema_h_78.jpg)