* cl_cmdrate - this should apparently be
approximately equal to the FPS you're getting (check netgraph). Too
much above or too much below and you'll get choke.
* cl_updaterate - you should set this as high as it
will go without causing ANY packet loss - if you're getting any loss,
that's BAD.
* rate - capped at 20000 for online play (25000 at
LAN). Setting it too low will cause choke. Setting it too high will
cause choke.
* ex_interp - the "ideal" is supposed to be
1/cl_updaterate. NEVER set this to zero because CS uses your current
cl_updaterate, not the server's. Basically, the higher ex_interp, the
smoother play will appear, but true player positions will be less
accurate on your screen. Some people prefer to just set this low and
leave it there. (0.01)
There will be 2 parts to this guide;
Part1- I will list the rates and will explain some of them
Part2- I will give you the optimum settings for best play
Part3- Will answer common questions
Part1- I will list the rates and will explain some of them
Part2- I will give you the optimum settings for best play
Part3- Will answer common questions
PART 1
ms- When you have net_graph 3 on you will be able your
ms. Ms stands for millisecond. Ms is your delay from when you click the
button to fire to when it actually does this. Your ping is what effects
your ms. 0 is best but anything under 50 is really fine.
choke- Choke effects your shot registration. You
always want 0 but a little is alright, nothing above 20. To check your
choke net_graph 3.
loss- As with Choke you check it with net_graph 3. It
also effects shot registration and you want it at 0. However you never
want any loss as it makes a lot more of a difference.
rate- The # of packets of information you send to the server.
cl_cmdrate-This is the number of updates clients(you) send to the server and can contribute to choke.
cl_updaterate-This is a request value and a lot of the
times not the actual # of updates received by the client from the
server. The actual number is capped by the server side fps.
fps_max 101- Allows for 101 frames per second,
anything higher is worthless as the eyes cant tell the difference and
cs's max is 101 (inless using 3rd party program).
ex_interp- When playing counter-strike you may notice
that when you shoot someone it does not kill them. This is partly due to
the rates mentioned above and a lot to do with your ex_interp setting.
The two choices for this setting are ex_interp .1 and ex_interp .01.
When playing cs it may say you are getting 100 fps but you are really
getting x amount of real frames and x amount of guessed frames. Putting
your interp at .1 increases the amount of real frames you get and
consequently reduces your amount of guessed frames. At .01 you guess
more frames and shot registration is less accurate. However some people
think that .01 is best for AWP since you shoot far less and sometimes
the guess frame can hit the target when you really missed. Inless your
running on a old computer i suggest using .1 especially for rifles.
PART 2
rate- 20,000, some say 25,000 but servers are maxed out at 20,000 so it does'nt matter.
cl_cmdrate- 101
cl_updaterate- 101
ex_interp- This is an opinion but i suggest .1(.1 is required at all lan tournaments also).
cl_cmdrate- 101
cl_updaterate- 101
ex_interp- This is an opinion but i suggest .1(.1 is required at all lan tournaments also).
PART 3
Where do i enter the commands? You enter these
commands in the console. To open your console press the ~ button. I am
not sure but in source you have to activate it by going into
options->advanced settings and check the box for enabling the
console.
How come ex_interp is locked at .01? I am not exactly
sure but i know .001 is considered to be hacking by VAC. If you own a
server you can change the server.cfg file to allow .001 and more but its
not advised.
I used your suggested rates but i have lots of choke
and loss. The rates i provided are the best rates for most servers,
however for some servers you will need to change them to lower your
choke etc. Remember your goal is 0 choke/loss/ms.
How are you so cool? Some people are just born that way what can i say :smile:
Final Verdict: If you can have your rates as i suggest
and get 0 loss/choke then use them, otherwise you can alter them to
however you like!
-Scott Tschida
Recommendations for online play:
rate:
I’ve been assured that rate is capped at 20000. Using anything above 20000 has no benefit, and could potentially lower performance.
I’ve been assured that rate is capped at 20000. Using anything above 20000 has no benefit, and could potentially lower performance.
Recommendation:
rate 20000.
rate 20000.
sv_maxrate:
This value will most likely be set to 0. I’ll explain why this might not be the optimal value for online play. sv_maxrate 0 will detect each clients’ rate setting and fulfill each players’ need. Assume for a second that the half-life engine did allow players to use a rate value of over 20000. If a player had rate set to an insanely high value (i.e. 999999999), the server would try to fulfill that need. This could potentially waste bandwidth and put more load on the server than needed. I suggest a safer, but equally well performing value of sv_maxrate 20000. In reality, sv_maxrate 0 and sv_maxrate 20000 may behave exactly the same, but added precautions never hurt.
This value will most likely be set to 0. I’ll explain why this might not be the optimal value for online play. sv_maxrate 0 will detect each clients’ rate setting and fulfill each players’ need. Assume for a second that the half-life engine did allow players to use a rate value of over 20000. If a player had rate set to an insanely high value (i.e. 999999999), the server would try to fulfill that need. This could potentially waste bandwidth and put more load on the server than needed. I suggest a safer, but equally well performing value of sv_maxrate 20000. In reality, sv_maxrate 0 and sv_maxrate 20000 may behave exactly the same, but added precautions never hurt.
Recommendation:
sv_maxrate 20000.
sv_maxrate 20000.
cl_cmdrate:
Ideally, this value should equal the server’s fps (NOT the client fps as some people originally thought). If you update the server more times than the server calculates frames over the same time period, the extra updates are most likely just dropped by the server. Therefore, too high of a cl_cmdrate shouldn’t be too harmful, but will waste your bandwidth.
Ideally, this value should equal the server’s fps (NOT the client fps as some people originally thought). If you update the server more times than the server calculates frames over the same time period, the extra updates are most likely just dropped by the server. Therefore, too high of a cl_cmdrate shouldn’t be too harmful, but will waste your bandwidth.
Recommendation:
cl_cmdrate equal to or higher than the server’s fps.
cl_cmdrate equal to or higher than the server’s fps.
ex_interp:
Set this variable to 0 and nothing else. Counter-Strike will automatically set your ex_interp to 1/cl_updaterate (i.e. your console will say: “ex_interp forced up to xx msec”). This is because the time in between each packet is exactly 1/(the # of updates per second), so this is how long you want your client to interpolate. Adjusting your cl_updaterate will automatically adjust your ex_interp (when ex_interp is set to 0). I recommend only changing your cl_updaterate, and letting Counter-Strike set your ex_interp. You cannot set this command lower than 1/cl_updaterate anymore, and setting it higher is an exploit. Using a value above 1/cl_updaterate forces you to shoot behind the actual model displayed on your screen, which should be considered an exploit. For example, if you use cl_updaterate 101, the correct value for ex_interp would be 1/101 = 0.009 (9 milliseconds), but by using the default value of ex_interp 0.1 with this high cl_updaterate, the aforementioned exploit appears.
Recommendation:
Set this variable to 0 and nothing else. Counter-Strike will automatically set your ex_interp to 1/cl_updaterate (i.e. your console will say: “ex_interp forced up to xx msec”). This is because the time in between each packet is exactly 1/(the # of updates per second), so this is how long you want your client to interpolate. Adjusting your cl_updaterate will automatically adjust your ex_interp (when ex_interp is set to 0). I recommend only changing your cl_updaterate, and letting Counter-Strike set your ex_interp. You cannot set this command lower than 1/cl_updaterate anymore, and setting it higher is an exploit. Using a value above 1/cl_updaterate forces you to shoot behind the actual model displayed on your screen, which should be considered an exploit. For example, if you use cl_updaterate 101, the correct value for ex_interp would be 1/101 = 0.009 (9 milliseconds), but by using the default value of ex_interp 0.1 with this high cl_updaterate, the aforementioned exploit appears.
Recommendation:
ex_interp 0.
cl_updaterate:
It has long been thought that the prescription for cl_updaterate was to start at 101 and work your way down until you receive and acceptable amount of “choke.” Choke can be viewed by using the command net_graph 3. Personally, choke is the last thing on my mind. The best value for cl_updaterate is much more complicated. The CAL server side config provides for an sv_maxupdaterate of 101, so one may conclude that your cl_updaterate should be set to 101. Ideally, this is correct, but in reality is not very useful. Most servers you will play on in North America won’t be able to calculate 100 frames per second; this means that there is no way the server can send out 100 updates per second. Therefore, a value of cl_updaterate 101 will tell your client to use ex_interp 0.009, but you won’t actually be receiving 100 updates per second, so the players will appear choppy. Since there is no way to determine a server’s fps without rcon (again use rcon stats), the optimum value is somewhat of a guessing game. You might say, “Well, just set cl_updaterate to 101 anyway and I’ll receive the maximum number of packets the server can send.” The problem here is the disregard of cl_updaterate’s effect on ex_interp and the delicate balance that must be maintained between them.
To find your optimum value of cl_updaterate (remember to set ex_interp to 0), start at 101 and work your way down until the models only slightly skip around. “Slightly skip around” is a matter of preference, as long as ex_interp equals 1/cl_updaterate, the models will be in the right place. You will need to readjust your cl_updaterate on a per-server basis. Don’t be afraid to use a value under 50, if necessary. The prediction engine will do its job. Note: most public servers will be using the default sv_maxupdaterate value of 30, so cl_updaterate 30 will work best in that situation.
It has long been thought that the prescription for cl_updaterate was to start at 101 and work your way down until you receive and acceptable amount of “choke.” Choke can be viewed by using the command net_graph 3. Personally, choke is the last thing on my mind. The best value for cl_updaterate is much more complicated. The CAL server side config provides for an sv_maxupdaterate of 101, so one may conclude that your cl_updaterate should be set to 101. Ideally, this is correct, but in reality is not very useful. Most servers you will play on in North America won’t be able to calculate 100 frames per second; this means that there is no way the server can send out 100 updates per second. Therefore, a value of cl_updaterate 101 will tell your client to use ex_interp 0.009, but you won’t actually be receiving 100 updates per second, so the players will appear choppy. Since there is no way to determine a server’s fps without rcon (again use rcon stats), the optimum value is somewhat of a guessing game. You might say, “Well, just set cl_updaterate to 101 anyway and I’ll receive the maximum number of packets the server can send.” The problem here is the disregard of cl_updaterate’s effect on ex_interp and the delicate balance that must be maintained between them.
To find your optimum value of cl_updaterate (remember to set ex_interp to 0), start at 101 and work your way down until the models only slightly skip around. “Slightly skip around” is a matter of preference, as long as ex_interp equals 1/cl_updaterate, the models will be in the right place. You will need to readjust your cl_updaterate on a per-server basis. Don’t be afraid to use a value under 50, if necessary. The prediction engine will do its job. Note: most public servers will be using the default sv_maxupdaterate value of 30, so cl_updaterate 30 will work best in that situation.
Please note that starting from a low value of
cl_updaterate (such as 20) and working your way up will not work. Once
you increment cl_updaterate to a higher value, the ex_interp will not
reset itself automatically; you will have to manually type ex_interp 0
again and again. Here is a convenient script I’ve written for adjusting
cl_updaterate easily:
Update Rate Config File
Recommendation:
cl_updaterate should equal the server’s fps, and shouldn’t exceed the server’s sv_maxupdaterate value.
cl_updaterate should equal the server’s fps, and shouldn’t exceed the server’s sv_maxupdaterate value.
sys_ticrate:
Finding the optimum value for sys_ticrate involves some experimentation. First, recall that if your server is not boosted, raising this value above 100 will have absolutely no effect. If you happen to rent from a high performance server provider (read: your server is boosted), then you have some room to work. While generally more fps is a good thing, the effects of increasing sys_ticrate over about 200 (probably even lower) are almost non-existent. If you set sys_ticrate to 9999, your server’s fps may fluctuate between say 150-1000 depending on the complexity of the current situation. Setting sys_ticrate to a value under 200 would provide a more consistent environment with a minimal (if any) loss in performance. Also, every server host out there runs multiple instances of HLDS (Half-Life Dedicated Server) on one physical server (computer), so if every instance of HLDS is set on sys_ticrate 10000, the load on the CPU(s) could become too great. This type of situation could potentially degrade the playing experience for every server hosted on that computer (and raise your monthly rent).
Finally, server fps only works in multiples of certain numbers. For example, my server will only run at 85, 102, 128, 170, 256, etc. fps and not in-between. If you set sys_ticrate to 100, your server will run at the highest multiple that is under 100 (ex. 85), so try setting sys_ticrate 20-50 above your target fps.
Finding the optimum value for sys_ticrate involves some experimentation. First, recall that if your server is not boosted, raising this value above 100 will have absolutely no effect. If you happen to rent from a high performance server provider (read: your server is boosted), then you have some room to work. While generally more fps is a good thing, the effects of increasing sys_ticrate over about 200 (probably even lower) are almost non-existent. If you set sys_ticrate to 9999, your server’s fps may fluctuate between say 150-1000 depending on the complexity of the current situation. Setting sys_ticrate to a value under 200 would provide a more consistent environment with a minimal (if any) loss in performance. Also, every server host out there runs multiple instances of HLDS (Half-Life Dedicated Server) on one physical server (computer), so if every instance of HLDS is set on sys_ticrate 10000, the load on the CPU(s) could become too great. This type of situation could potentially degrade the playing experience for every server hosted on that computer (and raise your monthly rent).
Finally, server fps only works in multiples of certain numbers. For example, my server will only run at 85, 102, 128, 170, 256, etc. fps and not in-between. If you set sys_ticrate to 100, your server will run at the highest multiple that is under 100 (ex. 85), so try setting sys_ticrate 20-50 above your target fps.
Recommendation:
sys_ticrate 110-180, depending on the quality of your server.
sys_ticrate 110-180, depending on the quality of your server.
Notes about LAN play:
The reason LAN organizations, such as the CPL, use cl_updaterate 101 has to do with the quality of servers they host. Usually on LAN, only a few servers will be running on any given box, so the servers use up fewer resources. If the servers are boosted to over 100fps, then cl_updaterate 101 becomes a realistic value. For a quick way to determine if a LAN server is boosted, look at the average ping of the players. A default server running at 50 or 64fps will yield pings above 15ms, while a boosted server will produce much lower pings, on the order of 5ms. To my knowledge, the CPL, ESWC and WCG all use boosted servers.
The reason LAN organizations, such as the CPL, use cl_updaterate 101 has to do with the quality of servers they host. Usually on LAN, only a few servers will be running on any given box, so the servers use up fewer resources. If the servers are boosted to over 100fps, then cl_updaterate 101 becomes a realistic value. For a quick way to determine if a LAN server is boosted, look at the average ping of the players. A default server running at 50 or 64fps will yield pings above 15ms, while a boosted server will produce much lower pings, on the order of 5ms. To my knowledge, the CPL, ESWC and WCG all use boosted servers.
0 comments:
Post a Comment