No announcement yet.

Adjusting your rates - An In-Depth Guide

  • Filter
  • Time
  • Show
Clear All
new posts

  • Adjusting your rates - An In-Depth Guide

    Wyz mentioned that a guide to adjusting the in-game bandwidth settings was needed, so I decided to write one up. I'll include sources at the end in case anyone wants to go back and see where I got my information from. Some of the information comes straight from my head: 5 years of experience with the HL engine in two competitve environments (First TFC, now NS) have seared the knowledge into my brain. I'm providing documentation due to Wyz's request. Keep in mind the Guide I chose to follow (the best one that I've ever found) is quite dated, so use the numbers I give under bandwidth settings instead. I know the better values than they give, since connections then weren't quite as good.

    First an explanation about the history of the Half-Life netcode. I'm sure most of you know that HL uses a highly modified Quake 1 engine with the Quake 2 renderer. The original netcode was identical to Quake 1. That is, the lower the latency, the faster your information got to and from the server. People could snipe you with the crossbow in HLDM before you could even see they were there. At the time, most of the world (greater than 90%) was gaming with Dial-up of some type, so everyone pinged fairly high. Below 250 ping was pretty good, less than 100 drew the scorn of everyone in the server. Your FPS (or frames per second) was also tied into your ping, which made having a crappy computer worse than a crappy connection. After a year of this, Valve released an updated netcode in the HL patch.

    The patch introduced client side prediction for movment, weapons firing, and decals. The result of that is this: A player with 300 ping (Now referred to as Player A) and 100 ping (Player B) were now on equal footing. For example, Player A sees Player B in a game of TFC. Player A hits Player B with a sniper rifle round to the head on his own screen. Player B sees Player A at the same time, and moves behind a wall. Now here's where the client side prediction comes into play. Player A's client sends the information that a shot was fired at a precise moment (tick) in the game. That information must first get to the server, then be relayed to the other players once the server decides if the shot hit or missed. If it hits, it will register on the player it hit as soon as the information reaches them. Remember that Player B had moved behind a wall on seeing Player A? Well, Player B thinks he's safe, until half a second later he suddenly dies from a headshot behind the wall. This is what you see a lot of the time, a very long pause in the registration of hits. This was just so you understand some of the commands I'm about to list, and understand what they do.

    First the client side prediction commands. cl_lc 1/0 enables or disables lag compensation (all variables here are boolean: 1 for on, 0 for off). This is the most basic client side prediction, and allows you to play by the rules I posted in the above paragraph. Most people have never played with it off, so I recommend leaving it on: It's a completely different game with it off. Weapons require leading due to lag if you disable it, so I strongly recommend leaving it enabled (which it is by default). Next is cl_lw. This is for weapons animations and sounds. If cl_lc is on, leave this on as well. It is what's responsible for generating the weapons firing animations and sounds. Back in the day these were lagged as well, since they were sent to the server to confirm you actually fired before the animation/sound were played. Turning them off makes the server verify the weapon fired before the sound/animation is played. Turning this off while leaving lag compensation on is suicide, since you don't be able to judge if bullets are landing or not until it's way too late. The last variable is cl_lb. This controls the blood prediction if weapons prediction is turned on. You may turn this on or off at your discretion, see if you can correct your aim better with it on or off and base your decision off of that. Now on to the bandwidth settings.

    To help test these commands, let me introduce everyone to our friend, Mr. Netgraph. By typing net_graph 1 in the console, you enable Mr. Netgraph. You may also use net_graphpos 1/2/3 to adjust where on the screen the graph is located (1 is bottom left, 2 bottom center, 3 bottom right). A picture explaining what all the information on Mr. Netgraph means can be found at this URL:

    First is an explanation of the numbers for rate and cl_rate. The numbers are in bytes per second. So a 14.4K modem would optimally use about 1500, roughly the speed of the modem. The rate setting controls how much you attempt to download from the server. Take whatever your connection speed is and adjust it accordingly. Remember that connections now are much faster and reliable than most guides will assume, so you can put your settings higher. Everyone on Cable/DSL should be able to use at least 10000. I have 512K Cable right now and I use 20000 with no problem. You must figure out for yourself what the best value is. cl_rate is the speed at which you upload to the server. Once again, find a value that's appropriate for your connection. Most can handle 10000, others can go up to 20000 (like mine) with no problems. 20000 is the max setting allowed by the half-life engine for both cl_rate and rate. Next are the command rates. cl_updaterate is the number of updates per second sent to the server. The higher they are, the more information updating the server to your location and actions will be sent. At this point, type net_graph 3 into the console. Notice the bar goes away and numbers replace it. One is for loss: the number of packets sent but not recieved. Choke is packets that can't be sent or recieved. The default is far too low for any real broadband connection. I suggest walking it up, starting with 30, at increments of 10. When you reach a point that you start getting choke higher than 1-5, adjust by values of 1 until the choke dissapears. Another value is cl_cmdrate. This is the number of commands you download from the server per second. Adjust is just like cl_updaterate. Both of these commands should be somewhere between 30-50 for even lower end broadband connections. The max setting is 60 according to the Half-Life engine, however most people bump them to 101 each if they can handle it, just to be safe.

    While not a command that affects latency anymore, I felt fps_max should be included in this guide. With the netgraph on, you can see your FPS. cl_showfps 1 will also show the FPS in the upper left-hand corner of your monitor. In certain situations, your FPS will drop suddenly, causing choppiness on the screen. This affects most computers that aren't beasts, even mine at times. You can lock your FPS so that they never go above a certain number. Try to find a stable number that your FPS almost always stays at, and lock it slightly below that number. I have a solid computer, so I use fps_max 72. It's much easier to aim when your FPS isn't moving around a lot, and a number slightly lower than what it's stable at should keep it steady, increasing your accuracy in high screen-lag situations.

    Now would also be a time to check your refresh rate. While it varies from monitor to monitor, most people playing at 1024x768 to around 1280 x 1024 can get away with increasing their monitor refresh rate to 75 Hz from the default 60 Hz. This allows you to raise your frame rate above 60 fps (which some of you are probably locked at). More importantly, it decreases eye strain by displaying all information on the screen faster, at a rate your eyes can see easier. I'm sure some of you have had headaches or your eyes hurt after staring at a monitor for a while. You can adjust this by going to Display Properties in the Control Panel (right clicking for those of you without a replacement windows shell) > the Advanced button > Monitor Tab > Screen refresh rate drop-down box. Sometimes removing the X from the Hide modes monitor cannot display button allows you to access refresh rates that Windows won't allow you to use, yet your monitor will. If the refresh rate is too high, the screen will turn black. Simply wait 15 seconds, and windows will restrore you to your previous refresh rate. Find the highest one you can do to, and use it.

    Keep in mind the higher the resolution, the lower the maximum refresh rate you can use. Only the better monitors can use 75 Hz at 1600x1200 and higher, most can't use 75 Hz any higher than 1280 x 1024. If you can't use 75 Hz at your current screen size, I highly suggest either lowering it, or if you're already down to 800x600, seriously consider buying a new monitor. Your eyes endure a lot of strain using 60 Hz. I had to buy a newer monitor to get higher refresh rates, because the strain on my eyes caused terrible miagraines. Just a bit of advice from someone who knows about the pain refresh rates can cause.

    This concludes the guide, I hope everyone finds it very useful. My source for this guide was Tweak3D.Net's Half-Life Netcode Guide, found at
    I've quoted from this guide several times. I suggest everyone read if for the other information it has that wasn't pertinent to this guide I've posted. It has a few other visual goodies.
    Last edited by TheAdj`; 05-21-2004, 11:49 PM. Reason: Typo edits

  • #2
    Re: Adjusting your rates - An In-Depth Guide

    Here is one that I have, though this is way back when, hehe look at the date. It is CS oriented but that makes no difference.
    Half-Life Netcode Explained
    Written by Andreas Thorstensson <[email protected]>
    December 23, 2001

    I think Counter-Strike should be played as much default as possible. The colors, the textures, the shadows etc are all essential parts of a Counter-Strike map. Every corner and dark spot is taken into consideration when you create your tactics and your positions. That should not change. But I still believe that the personal aim skills should pay off and that you really hit where you actually aim. The more random the game gets the more frustrating it is for people that put alot of time into it to escalate on the skill ladder.

    Behind the netcode
    The server or gameworld gathers everything that is going on in the multiplayer game. The client sends information or packets with actions issued by the player, movement, firing and so on. The server receives the packets, calculates the information, is it a hit? is it a headshot? and then sends that information back to the client (player). The goal of the netcode is to make it work with every connection and to behave as smooth as possible.

    The flaws of the netcode in HL
    Everyone who played games with the Half-Life engine before the new netcode (before remembers the game to be super accurate for players with low ping, and that you had alot higher ping with ISDN and modem compared to the new engine. In the new netcode Valve wanted the game to use less bandwidth to lower the pingtimes for ISDN and modem. To do this they changed the time the client sends updates to the server and the time the server sends the updates to the clients. With less client-server and server-client communication a smaller amount of bandwidth needs to be used. But because of that, the server-client and client-server communication is delayed.

    With delayed server-client communication the players would move extremely jerky on screen. So they added interpolation. Interpolation takes the position of the semi-last known position of a player and moves it to the last known position during a period of time, interpolation time. On the other hand (and what Valve likes) with delayed server-client communication packetloss does not feel as bad.

    In the old Half-Life netcode the client-server communication was based on client FPS (frames per second). The FPS decided how many updates were sent to the server. In the new netcode the case is not so. And with default settings the Half-Life engine bases the updates on a 30 FPS average.

    The flaws of the HL server
    There is a flaw of the HL server which makes it idle between every serverframe (update to the clients). This causes the game to be less responsive and adds higher pingtimes.

    Default added lag
    How much lag do I get by default settings?

    Lets do some simple math here:

    Server-client lag
    An average HL server runs with about 20 fps (server frames) and default server-client update is 20:
    1000ms / 20 = 50ms

    *EDIT* Our server runs at ~150FPS
    Client-server lag
    The default client-server update is 30
    1000ms / 30 = 33ms

    Interpolation lag
    The default interpolation is 100ms

    50+33+100 = 183ms

    So your actual latency is your ping + 183ms (in the worst case). A ISDN player will average about 230 ping.

    Why do I hit at all?
    Because Valve has added lag compensation. With lag compensation every packet received to the server is examined and its latency is reduced by the engine. So in this way it still "works" even with high ping. And it also (of course) works the same with low ping.

    Why does it feel so smooth on my client even with high ping?
    If you have played on a server with very high ping you feel that the weapons still are dead instant, when you hit that fire button the weapon reacts immediately and is being fired. In the new engine much of the multiplayer information is calculated on the client for visual effects. The client estimates were players are, it adds blood when you hit and also adds those bullet holes and marks on walls. But those are not true, they are only estimations and you never know if they are real. Only the server knows, and when you receive the correct update from the server the player that you aimed at will eventually die. And then you know for sure.

    QuakeWorld worked great
    The QuakeWorld server is very different compared to the HL server. It always sits waiting for packets to be sent to it. As soon as it gets one, it calculates the data and immediately sends it back to the client. Because of this QuakeWorld does not need interpolation. The only lag caused by QuakeWorld is the client-server updates (which are based on FPS as in the old Half-Life engine).

    So lets compare added lag with other games:

    As we said before adds up to 183ms lag.

    No server frame delay and no server-client delay
    Client-server communication is decided by client FPS which has a maximum of 72 in QW
    1000ms / 72 = 14ms
    No server-client delay
    No interpolation

    0+14+0+0 = 14ms

    Quake 3
    The default server fps is 20 and default server-client update is 20
    1000ms / 20 = 50ms
    The default client-server update is 30
    1000ms / 30 = 33ms
    The default interpolation is 50ms

    50+33+50 = 133ms

    What can I do?
    So do I have to play another game to get accurate netcode? No you do not, the good part of all this is that you can tweak, or better put, "fix" those flaws.

    Lets start with client commands:

    Default: 20
    Suggested: 20-100 depending on bandwidth, if your net_graph is falling and rising decrease this value.

    Default: 30
    Suggested: Equal to your average framerate (remember max FPS in Half-Life is 99/100) or a divisor of it if your bandwith doesnt handle it. If you have a steady FPS near 99, make sure to put this value above 100.

    Default 0.1
    Suggested 0.05-0.1
    Decreases the interpolation time, i.e the smoothing of the movement. The players will move more jerkily but more accurately.

    Default: 1
    Suggested: 1
    Set to 0 removes the lag compensation totally, only works on LAN and with a very low ping.

    Default: 1
    Suggested: 1/0
    Set to 0 removes the client-side behaviour of weapons and hits. A fired bullet (packet) is sent to the server and then returned to verify if it was a hit or not. Now you know for sure you did hit. But it only works fine on LAN and with low ping.

    Now to server problems:

    Thanks to Zibbo from UDPSoft who has released HLDS Ping Booster a fixed version of the HL server, you can increase the server fps heavily. The only drawback is that the server requires alot more CPU. You can then limit the server-client traffic with sv_maxupdaterate, default is 100.

    So how much can I reduce the added lag?
    Lets do the same maths again. Now we use the HLDS Ping Booster (maxupdaterate 100), we use cl_updaterate 100, cl_cmdrate 100 and ex_interp 0.

    Server-client lag
    A ping boosted HL server (with maxupdaterate 100) and server-client updates with cl_updaterate 100
    1000ms / 100 = 10ms

    Client-server lag
    Client-server updates with cl_cmdrate 100
    1000ms / 100 = 10ms

    Interpolation lag
    No interpolation

    10+10+0 = 20ms

    From 183ms to 20ms with settings and the HLDS Ping Booster. Quite impressive.

    Note: Using ex_interp 0 is not really recommended and is alot about personal taste, try values around 0.05.

    I dont want to be a netcode/config cheater! Lets face it, why is it a cheat to make sure that what you see is also what the server sees? Take a basic example, with default cl_cmdrate and with an avg fps of 90 (quite common for the average player), only every 3rd frame you see on screen is true, the two other frames are totally ignored by the server (it does not know about them). How accurate is that? No wonder alot of people randomly says "useless game" while they are playing.

    The commands are here, now just use them in a correct way. And last but not least, lets play the game as it was intended, with default graphics, sounds and models but with accuracy!
    Please do not mess around with this value "ex_interp" I was once banned from a server cuase i had it at .03
    Last edited by Emanon; 05-21-2004, 11:31 PM.


    • #3
      Re: Adjusting your rates - An In-Depth Guide

      That was a bit complicated for this Emanon, that's why I didn't copy/paste something, I wrote one myself. I didn't want to get into interp and such.


      • #4
        Re: Adjusting your rates - An In-Depth Guide

        Ya, oh well.

        Short version for those who dont want to read.

        If you have DSL/Cable
        cl_updaterate 50
        cl_cmdrate 50
        rate 10000-20000

        Modem, start preying, not much you can do.


        • #5
          Re: Adjusting your rates - An In-Depth Guide

          lol, I see the interp edit. I may talk about that later.


          • #6
            Re: Adjusting your rates - An In-Depth Guide

            Originally posted by TheAdj`
            lol, I see the interp edit. I may talk about that later.
            Caught me :icon_bigg


            • #7
              Re: Adjusting your rates - An In-Depth Guide

              You forget, I'm a comm, it's my job to notice even the small things.


              • #8
                Re: Adjusting your rates - An In-Depth Guide

                woah. my settings were way off. thanks for the guide.




                TeamSpeak 3 Server


                Twitter Feed