wheelchairjihad.com

Raggi’s Rates Guide - Unchanged for sometime

Step 1 - Back to Basics
If you’ve been fiddling and don’t have defaults, delete your config.cfg from Valve\Steam\SteamApps\{username}\Counter Strike Source\cstrike\cfg, and remove any other configs that have rate related settings in them if you have any.

_{Rationale:
Valve work off their defaults, and they’ve been continually improving and fixing the netcode for a long time now, defaults aren’t optimal, but they’re the best place to start.}

Step 2 - Load CounterStrike? Source?
Click.. no, you can do this bit on your own.

_{Rationale:
Too dumb for that? If yes, step away from the computer.}

Step 3 - Console
Go to options -> keyboard -> advanced -> enable the console.
click ok to the otions boxes
press the ` key (top left, to the left of the 1 key)

Step 4 - Rate
Type ‘rate’ into the console and press enter.
It will respond with:

Quote

Max bytes/sec the host can receive data

This means, you should set ‘rate’ to the maximum number of bytes your computer can recieve a second.
In simpler terms, this is asking for a value for the speed of your internet connection download speed.
2mbps from your isp is roughly 200000 bytes per second, or ‘rate 200000′
1mbps from your isp is roughly 100000 bytes per second, or ‘rate 100000′
512kbps from your isp is roughly 51200 bytes per second, or ‘rate 51200′
256kbps from your isp is roughly 25600 bytes per second, or ‘rate 25600′
128kbps from your isp is roughly 12800 bytes per second, or ‘rate 12800′
And so on, hopefully you can work out any others on your own.

_{Rationale:
The IN GAME documentation says to set it like this. If the incoming data exceeds this rate, you will recieve choke, and if rate is set higher than your connection can handle, when lots of data needs to be sent you will get loss. Both loss and choke are bad for your gameplay when created in this manner. Rate is a capping value, setting it higher than the server would normally send is NOT problematic in any way. Servers have a variable called sv_maxrate which takes priority if lower than a clients rate setting. There is alot of talk out there that rate is capped at 20000, or 30000. The 20000 idea comes from 1.6, and is very much false information. The 30000 comes from Whisper, over on the HLDS mailinglists, who was apparently provided this value by Valve employee Alfred Reynolds. I have not found this email on the lists, and assume that the lack of ingame documentation about a limit, and the fact that in practice I have seen over 40000 bytes per second of traffic from a server to a client, deny the existance of such a limit. Furhtermore the claim is that it’s hardcoded, so if it were so, setting it higher would future proof you for later versions of Source, and, would not negatively affect anything at all, in any way, ever.}

_{My numbers come from this:
ISPs sell bandwidth decimally similar to harddisk manufacturers. So 1mbps is 1*1000*1000bps, (not *1024).
If you don’t get this, let me elaborate further….
mbps*1000 = kbps
kbps*1000 = bps (bits per second)}

_{To turn bps into bytes, this is bps/8. Ideally though, you want to add some leeway for other things, so bps/10 is suitable here. Thus 2mbps is 2*1000*1000/10 or 2*100000, 200000.
Update 21 Jan: It’s now been said that the value for rate has been clamped to 30000. This, however, doesn’t mean you can’t set rate accordingly to your internet connection just in case this new limit (note ‘new’ limit) is removed in future.}

Step 5 - Updaterate - ‘Your view’
A quick bit of math is required here…
Take your value for ‘rate’ and divide it by 200.
This value is your connection speed based maximum for cl_updaterate.
Example: 128k connection:
12800 / 200 = 64.
Round DOWN (always down) to a whole number if necessary.

_{Explanation / Rationale:
Valve have never officially said “we regard an update packet to be a maximum of X bytes in size”. However, they have said, we can expect 53.6Kbits per second per player of bandwidth usage on servers. Here: http://support.steampowered.com/cgi-bin/steampowered.cfg/php/enduser/std_adp.php?p_faqid=108
A normal server is 33 tick, or about 33 packets a second, so we’re looking at 53.6/33 which is roughly 1.6Kbits per packet, or around 200 Bytes. With emperical testing, this rule seems to hold about true as a higher bound value. A 100 tick server can often send over 15 KB/s when there’s lots going on.
You can often get away with setting this higher, but when it does cause a problem, you are going to guarantee an effect on your game by doing so.
Update: A recent update to the game has removed the ingame documentation stating a maximum value for updaterate. This may be future proofing in the Source engine to later handle servers at over 100pps rates. Either way, the code seems to now happily take higher updaterates, there is no integer overflow, so the < evaluation works fine for higher values.}

Step 6 - Commandrate - “Servers eye”
Right, we need to do some maths here too, and you’ll need to know your connections upstream speed. You’ll also want to know your average framerate.
Like with rate, we need a value for your upstream speed, for example if you have 256Kbps upstream, it’s 25600.
Divide that value by 200, the answer is your bandwidth limit for cmdrate.
e.g. 64Kbps upstream: 6400 / 200 = 32.
Your average framerate is your second maximum limit for this value.
So, set cl_cmdrate to the LOWER of either your bandwidth limit for cmdrate or your average fps, OR an in game maximum of 100, if you’re that lucky.

_{Rationale
If you try to send more packets than your computer can generate (it will only make 1 packet per frame) then you will get server side choke for your command packets (actions, movements, firing). If your connection can’t take it you’ll get loss (which is really bad, in many cases).
Update: The ingame documenation for cmdrate now shows a maximum of 100.000000. This was at one time 101. In any case, I cannot see any human really needing to send their input accross the network more than every 0.01s.}

Step 7 - Interpolation delay - “We’re making history baby”
cl_interp is the delay between server time, and your clients time.
In other words, in cs:s you always play in the past.
This value defines how long in the past, in seconds.
_{Update 21 Jan: Due to a recent source update, cl_interp has been temporarily disabled (soon to be removed completely) and replaced with cl_interp_ratio. Generally the default cl_interp_ratio of ‘1′ is fine in most cases, but if you would like a more in-depth look into cl_interp_ratio, please take a look at the following article:
http://wheelchairjihad.com/boards/index.php?topic=210.0}

Valve have currently disabled cl_interp (soon to be removing it completely) so that cl_interp_ratio can take its place. The in game documentation for cl_interp_ratio is as follows..
Quote
Sets the interpolation amount (final amount is cl_interp_ratio / cl_updaterate).

This should be simple enough. The final interpolation amount is determined by cl_interp_ratio / cl_updaterate. For example, if you keep your ratio as default, and you have updaterate 100, then your final amount will be 1/100 = 0.01. It’s advised to set ratio to the default of 1 to start with. As long as you have decently configured netcode (as per this guide) and are playing on a good server, you should have an accurate interpolation amount.

If you have an internet connection that suffers from constant loss, running cl_interp_ratio 1 will cause stuttering. If this is the case, set cl_interp_ratio 2 instead.

If you experience choke you should drop cl_updaterate. Simply put, the connection can’t handle the bandwidth required to distribute these packets and are being received ‘late’ on the server, which results in out-of-time corrections. If this is the case, setting cl_interp_ratio to a value around 1.5 will help with the stutteriness (is that even a word :p). However, you may still receive choke until you lower cl_updaterate.