What Is What?

If you played Counter-Strike, any Counter-Strike for that matter, for more than a few dozen hours, you probably know the situation of an opposing player peeking and killing you without offering the slightest chance of any reaction. Well, apart from the screaming “WTF” in voice chat that typically follows.

This small collection of information now aims to give you an overview as to how these situations arise and showcase a few ways to take the “WHAT?” out of WTF. To do so, we have to dip into some intricacies of CS:GO’s technicalities: Tickrates, interpolation, ping and even framerate are all concepts that need to be regarded when attempting to get a grasp on things like peeker's advantage. Granted, these are complex issues but I promise that you don’t need to be a network engineer to understand how that freaking T just killed you without being on your screen!

Most of the information displayed here is based on Valve’s Developer Community posting on Source Multiplayer Networking which can be found here. You can display some of the variables talked about here in-game by enabling your Netgraph via the command "net_graph 1" in the console.

Tickrate

In short: The tickrate determines how often the server updates what is happening on the server. MM Servers update 64 ticks per second, tournament servers at 128. A higher tickrate leads to a more “precise” calculation of what is happening and subsequently to better hit registration and easier bunnyhops.

Not many settings in CS:GO have been subject to such heated debates as the “Tickrate” has induced. Vocal players and full time redditors have been very vocal in demanding “128 tick servers” for a very long time, but what does tickrate actually do?

When joining a game of CS, no matter if MM, pug or community match, your pc – which we will be calling “client” from here on out – is establishing a connection to a specific server running the game. Intuition might tell us that this connection consists of a steady flow of information between the server and the client. However, due to the infrastructure of the internet and ultimately physics, a completely real-time communication between server and client cannot be achieved.

To work around this, the server draws information from the clients connected and updates the game accordingly in set intervals, so called ticks. The frequency in which the server does so per second determines our famous tickrate. On your standard 64 tick MM server, all actions of the server are updated 64 times in a single second or about every 15 Milliseconds, while the praised 128 tick tournament servers update around every .0078 seconds.

In theory, this incredibly small difference brings up multiple things. Firstly, CS:GO players seem to be incredibly skilled and receptive to notice such an incremental difference and, secondly, the question why Valve doesn’t simply provide all players with the best tickrate possible.

In practice, however, there is a reason why the numbers of people playing MM still vastly overshadow the subscribers of all pugging services combined. The people caring about higher tickrates are the high ranking minority actually able to tell the difference, as well as people looking for excuses why their spray over the whole distance of A-Long only connected with one bullet. I am not saying you should not be caring about having the best servers available. I’m saying that if you’re unable to reach that Global Elite status, it’s not the tickrate or resulting hit registration that is holding you back.

Video credit: /u/kinsi55

I already hear the screaming masses shouting for my blood because all this is not a valid reason for Valve to deny their paying customers the best possible service and you have a point with that.

Nevertheless, 128 tick servers are more demanding on bandwidths and general network quality than 64 tick servers and that is not only an issue on Valve’s end. People on atrociously slow internet connections are able to see the impact in their upload graphs. 128 tick servers require an upload bandwidth of at least 125kb/s to ensure smooth and packet-loss free gameplay. You might think that is a given in most developed nations today, but even some German villages might like a word about that.

Interpolation

In the last segment we learned that the server can only update what is happening in the game at certain rates. This information is then sent to all clients. However, the rate at which each client receives those updated information is partly specified by the users themselves.

Again, for most people on modern connections with reasonably strong PCs, all this is not an issue, as both their CPU and their bandwidth are able to support high rates. There are multiple console commands controlling this but to quickly recap:

• A client (player), playing on a 128 tick server,
• with “rate 128000” (telling the server how much bandwidth you have),
• “cl_updaterate 128” (requesting an update from the server 128 times/s)
• and “cl_cmdrate 128” (sending 128 updates/s TO the server),
• will receive and send 128 updating ticks about the game each second.

If you’re now sitting there and asking yourself how only 128 or much worse 64 ticks/s produce a playable game that is not stuttering crazily when receiving only 128 updates a second, you deserve a cookie. The answer is interpolation. When your game client receives a package from the server, it doesn’t simply show you the updated game world right away. This would result in everyone breakdancing in 128 or 64 tick intervals across the map. Rather, it waits a set interpolation time called “lerp”, whose name probably originated by a network engineer stepping on a frog.

During this time, a set number of further packages arrived on the client’s side containing more updated ticks from the server. Through these ticks, the client is able to interpolate what has happened between these two points in time and display this assumption to the player (don’t get mad yet). Interpolation time is determined by the simple equation

cl_interp = cl_interp_ratio / cl_updaterate

So in our 128 tick server example from above, on otherwise default settings this would mean: You receive a new packet every 7.8 Milliseconds (cl_updaterate 128) but the server waits until you received a third packet (cl_interp_ratio 2) before displaying the information, making the interpolation time is 15.6 Milliseconds for this example. On the other hand, a client running cl_interp_ratio 1 is presented with a renewed state of the game every 7.8 Milliseconds – assuming all other hardware and software variable are optimal.

Of course, from everything we’ve learned in our long online gaming history we assume that a lower number in front of the ms sign is always preferable. But, you already guessed it, things aren’t so easy this time around as bad connections and lag compensation come into the picture.

Again, the people with unreliable connections are better off to accept higher interp times, as the game client requires a new package of information from the server precisely at the interpolation time to update your game. If the second package is lost, the client waits 250ms on another package before flashing that red warning message in the top right corner of the screen.

For someone who tends to experience any package loss pretty much ever, it is safer to set cl_interp_ratio to 2, especially since you regain the “lost” time in the lag compensation.

Lag Compensation

The inevitable conclusion from the preceding segment and also the fact that all players on the server have a ping is, that everything you see on your screen has happened on the server already a few Milliseconds in the past.

Let’s leave any philosophical and Einsteinian implications of this to the side for the moment to focus on how a playable game is produced from this situation in which you don’t have to pre-aim your crosshair in front of the enemy.

The process responsible for this is lag compensation in which the server accounts for both ping and interpolation timings through the formula:

Command Execution Time = Current Server Time – (Packet Latency + Client View Interpolation)

Put into English this means that once you pull the trigger and this information package gets sent to the server, it then goes back from the current server time (the time the pulling the trigger package was received) by your ping plus your interpolation time. Only then it is determined if the client hit the shot or not.

Picture Courtesy of Valve Developer Community

The picture above shows such a situation with a combined ping and interpolation of 200ms, in which the red hitbox represents the model the client saw at the time of shooting, the blue hitbox the model the server saw and the CT represents the model in real time without lag compensation. The difference in those two hitboxes can be traced back to the described imperfection in the tickrates section. As the screenshot was taken on a 66 tick CS:Source server, the difference between server and client hitbox is quite noticeable and would gradually diminish with higher tickrate.

So what does that mean for you in your everyday matches?

Imagine you want to reach the boxes on top mid on Mirage while an AWP is perched in window. You jump out of the cover of the wall, fly and land safe behind the boxes. In the moment you land, the AWP shot goes off and you somehow die and end up right on the edge of the boxes, a good half meter away from where you stood on your screen. In the German scene, you would have just been “interped”, even though “being lag compensated” might be the more accurate term (I acknowledge that is way more clunky and less easy to complain about).

However, lag compensation enables CS:GO to be played online by a variety of players with different pings and interpolation times. While it might not be perfect and not the system we deserve, it is the system we need right now – as there is no alternative.

An Ingame Aggregation of Many Factors: Peeker's Advantage

With all we have learned by now, let’s look at peeker's advantage as one of the most prevailing manifestations of the netcode on game mechanics.

Video credit: /u/dolmakalem

The above comparison shows in motion what was described stationary in the lag compensation section. As the peeking CT moves into the gap of the double doors, his lag compensated hitbox and model are still behind the door, giving the Terrorist no real chance to respond. However, it is imperative in this scenario for the peeking player to actually hit (and in most cases kill) his opponent in the time it takes the server to compute all executed commands and the appropriate lag compensation. Of course, the showcased example is taken with a ping of 150ms, which is unrealistically high for most people, artificially lengthening that time.

Should any of you reading this have the good fortune to play on LAN one day, you should keep in mind that peeker's advantage is solely dependent on lag compensation, a big part of which is made up by a players ping. With the typical LAN connection ping of 3-7ms, peeker's advantage is practically non-existent anymore. Together with many other factors, this is one of the reasons why CS:GO has to be played differently in certain aspects on LAN than on the internet.

As on how to deal with peeker's advantage in your everyday MM games, voo CSGO recently released a nice video on how to hold angles:

The Last Few Things

If you have made it this far: Awesome! Paradoxically, it takes a long time to explain, showcase and understand things that happen in split-seconds. Through this whole guide we were dealing with as little as 1/128th of a second but the cumulative impact of all these tiny differences aggregate to a very real, very sensible distinction in playing the game.

However as the saying goes 90% of all errors sit in front of the keyboard and that is also true for CS:GO. When you find yourself complaining about bad hit registration or being interped five times in a single game, you should at first reevaluate your internet connection and net settings and then your gameplay. Tickrate and interpolation are things everyone has to deal with, yet somehow that guy still managed to headshot you without getting hit! Darn First-Shot-Inaccuracy!

As always, feedback and questions are greatly appreciated. You can leave them below or on reddit. Until next time, fellas.

Get your own AKRacing Chair here and support our players, all profit goes towards the teams!