|
|
|
|
|
|
|
|
|
|
|
 Descargas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Utilidades
|
|
|
|
|
|
|
|
|
|
|
|
Guias
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Como Ratear tu Server?
Bueno, como no podìa ser de otra forma tuve mirando gotfrag, y apareciò 1 artìculo que habla sobre la importancia del "net_graph"
Que es net_graph?
Es 1 herramienta ùnica proporcionada para ayudar a entender y optimizar el rendimiento In-Game. Tipeando en la consola "net_graph 1, 2 o 3" podès modificar y ajustar las opdiones net_graph.
Es una admisiòn echa por Steampowered, es una maravillosa herramienta para ayudar a diagnosticar porblemas de conecciòn y distinguir si el problema està relacionado con el cliente, el server o la red.
Porquè net_grap es importante?
Net_graph se puede utilizar para determinar errores importantes en los ajustes de red.
Tambièn, el net_graph es una herramienta importante usada por muchas ligas importantes para determinar si o un screenshot fue tomado durante partido en vivo o fue tomado en una demo del mismo.
Opciones para la optimizaciòn
cl_cmdrate (Nùmero de veces por segundo que el cliente manda informaciòn al server)
Mellin dice que: "Lo ideal serìa que este valor iguale los fps del server, NO los fps del cliente como la mayorìa piensan.
Si uno manda informaciòn al server màs veces que el server calcula los frames exedidos en el mismo perìodo de tiempo, la informaciòn extra mandada al server seguramente va a ser informaciòn perdida, osea que el server no va a recibir nuestra informaciòn, por lo tanto, el màximo de cl_cmdrate no debe ser demasiado grande, sino perderà ancho de banda."
cl_cmdrate ES un factor de sus FPS.
Para probar esto, conectese a su servidor preferido y tipee en la consola net_graph 1, mire sus fps actuales. Si su cl_cmdrate es MÀS BAJO que sus fps, notará los puntos rojos que son exhibidos abajo del gràfico:
Suba levemente el valor de cl_cmdrate sobre el valor de los fps y mire como los puntos rojos desaparecen:
Valve dice que: "El area final es la luz azul y (a veces) la roja al fondo del gràfico.
Esta lìnea se basa en sus fps y en su ajuste en el valor de cl_cmdrate. Por cada frame donde una serie de paquetes es actualizado y mandado cuando se updatea, la luz azul aparece en el gràfico. Si estas series son acumuladas cuando estamos updateando apareceràn los puntos rojos en el gràfico. Pruebe poner el valor de cl_cmdrate a la mitad de sus fps para ver el efecto."
De cualquier manera, los puntos rojos significan que su valor de cl_cmdrate es demasiado bajo y las series se estàn acumulando, porque usted tiene un valor de FPS más alto que el valor de cl_cmdrate.
cl_updaterate and ex_interp (nùmero de veces por segundo que el cliente pide informaciòn al server | tiempo de interpolaciòn)
"Nuestro valor de cl_updaterate debe ser igual al de sv_maxupdaterate del server en el que estemos."
"Esto trabaja de la misma manera que el cl_cmdrate. Deseamos mandar/recibir la cantidad de paquetes MÁXIMOS como sea posible."
Valve dice que en relaciòn con el gràfico el "àrea cuatro funciona correlativamente a como el cliente renderiza los cuadros. Por cada cuadro renderizado, el gràfico indica cuanta interpolaciòn fue utilizada en objetos.
Si no està consiguiendo un nùmero suficiente de actualizaciones del servidor o pierde bastantes paquetes, no podrà interpolar, y en lugar de interpolar, deberà extrapolar.
En este caso, se puede ver en la parte inferior del gràfico pasar por encima la línea grisàcea (sobre el àrea azul marino)se torna desde amarillo a rojo/anaranjado, dependiendo de cuanto tardan en llegar los paquetes.
Entonces, usando la información de Valve, debemos poder fijar el valor de cl_updaterate correctamente, y esto fijarà elex_interp a su valor correcto (solamente si su sistema fija automàticamente al ex_interp en 0).
¿Pero cómo encontrarlo cuando no sabemos el rcon?
Simple. Entre en su servidor favorito y tipee en la consola "net_Graph 1"
Ahora fijamos el valor de cl_updaterate a 51. Fijamos el valor de ex_interp a 0. Y automàticamente se setea ex_interp a cualquier valor. PERO, si miramos el gràfico. estamos recibiendo puntos amarillos/anaranjados, que quieren decir que estamos extrapolando. Sucede esto porque estamos recibiendo 51 paquetes, cuando el servidor puede enviar solamente 30 (sv_maxupdaterate 30). Por lo tanto, estamos perdiendo paquetes y estamos extrapolando. No deseamos esto asì que cambiamos nuestro cl_updaterate a 40, y nuestro ex_interp se fija automàticamente otra vez. Conseguimos este resultado:
Notese como los puntos amarillos son màs bajos comparado con el cuadro de cl_updaterate 51. Esto es porque todavìa estamos perdiendo paquetes porque recivimos solo 30 del servidor. Esto hace mala interpolaciòn otra vez, osea, extrapolamos. Cambiando nuestro cl_updaterate a 30, se fija el valor de ex_interp automáticamente y conseguimos esto:
Ahora, estamos recibiendo los paquetes máximos del servidor como es posible y por lo tanto no perdemos ningùn paquete. Por ende se fija nuestro ex_interp al valor correcto.
En conclusiòn, tenemos que emparejar nuestro cl_updaterate con el sv_maxupdaterate de los servidores en los que juguemos, de modo que podamos interpolar correctamente los movimientos del jugador basados en los paquetes REALES que recibimos y no se pierden.
Rate(lìmite màximo de bytes por segundo que el server puede mandar al cliente).
Bueno, todos tenemos que hacer que el rate aumente gradualmente, asi no recibimos choke cuando estamos en combate directo.
Esto garantiza que se estàn enviando y se estàn recibiendo todos nuestros paquetes, de lo contrario el valor de ex_interp es incorrecto.
cl_smoothtime
Valve dice que: "las predicciones de correciones de errores pueden ser absolutamente sensibles. Para alisar visualmente ese efecto, el error de la predicción se corrige gradualmente sobre una cantidad de tiempo corta (el cl_smoothtime)."
Personalmente, fijarìa esto a 0. En el caso que realmente no recibamos todos los paquetes del servidor, serìa a causa de lag, de un mal servidor, etc.
Deseamos ver la interpolaciòn de los paquetes REALES recibidos. Por lo tanto, si fijamos el cl_smoothtime a 0, nuestra interpolaciòn "no será alisada" o corregida y veremos la posiciòn real de los jugadores. Esto causarà un "salto" en los movimientos de los jugadores, pero estarà todo correctamente funcionando.
|
|
|
|
|
|
|
|
|
|
