Preface

I'm not a game developer but there's lots of FUD (fear, uncertainty, doubt) about rates. You shouldn't set your rates to rumours. I base my guide on previous Valve articles and own empirical testing. Rates won't win the game for you, but tuning your rates is a good idea. Default values are low.

Graphs

net_graph 1:

1. FPS (frames per second) & Ping (latency to the server in milliseconds)
2. Last received packet size in bytes / Traffic in kilobytes per second
3. Last sent packet size in bytes / Traffic out kilobytes per second
4. Ping graph. H eight = ping, Red = loss, Yellow = choke. You want low and stable graph. Loss means a lost packet due bad connection and choke means your rates are too low
5. Render (for every frame) and interpolation graph. Graph staying below the white line (at left) is good.
6. When interpolation turns into yellow and red like this, you are extrapolating ( bad)
7. cl_updaterate
8. cl_cmdrate
9. This is not in the picture, but at very bottom you'll get red dots if your cmdrate is below your FPS and your commands are cumulated for deferred sending

net_graph 3:

1. FPS (frames per second) & Ping (latency to the server in milliseconds)
2. Last received packet size in bytes / Traffic in kilobytes per second
3. Last sent packet size in bytes / Traffic out kilobytes per second
4. Lost & choked packets per second (lower better)

Inside NS Engine

Your NS view is an image updated x times a second (Frames Per Second). Everytime a new frame is constructed the HL engine reacts to your mouse, keyboard and checks for new updates (rate defined by updaterate) from the server. On each frame cycle, NS will send also updates of your actions to the server (rate defined by cmdate). Then it redraws your screen.

In NS interpolation means predicting events between two situations. For example, when a skulk is falling down to a pit, but NS only receives three packets from the server about it, NS will predict the movement path using the data of only these updates making it as smooth as possible. Without interpolation, there would be constant small warping. Extrapolation means NS does not have information about the location of eg. skulk and it has to guess where its going until server gives new information, which is bad generally.

Rate Settings

rate
Suggested: 20000

Rate controls the maximum amount of data (in bytes per second) you receive from the server. The current rate of traffic can bee seen on the 2nd line of net_graph 3. This variable is not really important as most of the time you will be getting below 10 000 bytes (9.7 kilobytes) per second anyway. Of course, if you have slow (eg. 12kB = 96kbit) or otherwise bad connection, you might want to turn this lower (so the server wont overflow your connection). Just as long as it is big enough to keep your choke off during intense fight, it is okay. Realistically anything over 20000 is just an overkill. 15000 means 14.65 kB/s (1kB = 1024 bytes).

cl_updaterate
Suggested: 102

This controls the amount of updates (an update tells what's going on) in seconds you receive from the server. This should be as high as possible the server allows, because naturally you want your to be kept up to date as much as possible. You cannot set it over 102. With normal computers and decent connection 102 is a good value. Too low or high updaterate can cause extrapolation (look above), but its better to keep it up at 102 and tune your ex_interp first than lowering updaterate.

cl_cmdrate
Suggested: FPS + 5

This controls the amount of updates you send to the server (eg. cmdrate 100 -> 1000ms/100 = 10ms) per second. You want to send updates at maximum rate possible and it should be a bit above your FPS. If it is below your FPS, updates will be accumulated for deferred sending, which is bad. Setting this notably over your FPS is pointless, since you cannot send updates faster than your game updates itself (defined by FPS).

You'll get red dots (in the picture cmdrate is 100 when FPS is 125) at the bottom of your net_graph if you set this below your FPS, which means your commands (movement, shooting etc.) is cumulated for deferred sending. If there're no red dots, you send an update to the server every frame which is good.

cl_cmdbackup
Suggested: 1

This determines the amount of backup packets (duplicates) are sent after each update (rate determined by cl_cmdrate) you send to a server. If you are experiencing loss, you can increase this but this also increases your upload traffic and "wastes" it (which can affect latency). 

ex_interp
Suggested: 0.01 - 0.10

This means how long you wait for updates until you draw stuff. Lower value means units will become choppier but more accurate, higher value means they'll be more smooth but less accurate. The unit is in seconds (eg. 0.01 = 10ms). Setting this to 0 will autogenerate the value for you, which will be 1/updaterate; eg. 1/100 = 0.01. This autogenerated value will also be the minimum value.

Any value between 0.01 - 0.10 is a good choice. Try it out yourself, you should see the difference. It also depends on a server: if I play on US servers, I usually increase this and lower when I play on EU servers.

When you tune this variable, you should see the the interpolation graph (purple graph) changing. More stable (straight) graph is better, and it definitely shouldn't go above the white marker (turns into extrapolation). Lower value makes the graph more jittery and higher value makes it more stable (at the cost of increased latency).

Here's a picture showing the difference between different ex_interps and server FPS. Interpolation can be seen in the purple graph below the green graph. The purple graph at left is desirable. So basically if I set ex_interp to 0.05 = 50ms, and I get update every 10ms (updaterate 100), my NS will wait 5 packets and then draw stuff, keeping it smooth but I have 50ms of hidden latency.

cl_lc and cl_lw
Suggestion: 1

This enables lag compensation (cl_lc) and local firing prediction (cl_lw). Lag compensation tells the server to calculate where you hit depending your latency (network lag + interpolation lag). So if you have 50ms ping and your interpolate 50ms (ex_interp 0.05), your total lag is 100ms which the server takes into account. This has to enabled on servers (its on by default) aswell. Lag compensation tries to make sure you hit when you hit stuff on your screen but this means others can get "cornered".

Local firing prediction (cl_lw 1) might cause you to see incorrect hits being registered but it no way changes the actual hit registration but only what you might see. There is no real harm done since you probably use your crosshair to aim, not the visual bullet path. On the bright side you will see the most likely bullet registration faster. You shouldn't turn this off since there'll be noticeable lag in all effects if you do. 

Conclusion

So in short, ideally in net_graph you would have a straight green line meaning a stable ping without any red dots (which is loss) and below that a stable (almost straight) purple line meaning your skulks are not jittery by tuning your ex_interp. At very bottom you don't want to see any red dots meaning you send your mouse etc. input to the server every frame.

Extra Reading

Best article about rates is probably this: Source Engine Networking

Its talking about Source engine but all that applies to HL1 aswell. Variable names are a bit different. Interpolation and lag compensation are explained very well in that article.

Other stuff:

Netcode Explained

Netcode Explained Again

Discussion on ENSL Forums

Date: 10/10/2007
Written by: jiriki
Credits for corrections: Anakin