How does CS:Go tick rates work?

CS:GO

Simplified & Summarized

Client-side:
fps var: low value = good
fps var: high value = bad
Server-side:
64 tickrate: sv < 15.625ms = good
64 tickrate; sv > 15.625ms = bad
128 tickrate: sv < 7.8ms = good
128 tickrate; sv > 7.8ms = bad

What is the difference between 64 and 128 tick servers?

Usually you can say the higher the tickrate, the more precise the simulation will be as the server is processing the data faster. This results in a better gameplay experience (more precise movement and hit-detection), because the server and the client are updating each other with a higher frequency.

Of course this is very simplified, but to understand the advantage of a higher tickrate, you firstly need to understand the basics of multiplayer networking within the Source Engine. Valve is running an official wiki with some good explanations how the netcode works in CS:GO.

This is the official explanation on how all these complicated networking commands work from Valve

“The server simulates the game in discrete time steps called ticks. By default, the timestep is 15ms, so 66.666… ticks per second are simulated, but mods can specify their own tickrate. During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. A higher tickrate increases the simulation precision, but also requires more CPU power and available bandwidth on both server and client.

The client and server communicate with each other by sending small data packets at a high frequency. A client receives the current world state from the server and generates video and audio output based on these updates. The client also samples data from input devices (keyboard, mouse, microphone, etc.) and sends these input samples back to the server for further processing. Clients only communicate with the game server and not between each other (like in a peer-to-peer application).

Network bandwidth is limited, so the server can’t send a new update packet to all clients for every single world change. Instead, the server takes snapshots of the current world state at a constant rate and broadcasts these snapshots to the clients. Network packets take a certain amount of time to travel between the client and the server (i.e. the ping time). This means that the client time is always a little bit behind the server time. Furthermore, client input packets are also delayed on their way back, so the server is processing temporally delayed user commands. In addition, each client has a different network delay which varies over time due to other background traffic and the client’s framerate. These time differences between server and client causes logical problems, becoming worse with increasing network latencies. In fast-paced action games, even a delay of a few milliseconds can cause a laggy gameplay feeling and make it hard to hit other players or interact with moving objects. Besides bandwidth limitations and network latencies, information can get lost due to network packet loss.”

You must be logged in to post a comment Login

Leave a Reply

Powered by themekiller.com anime4online.com animextoon.com apk4phone.com tengag.com moviekillers.com