Does Your Bullet Registry Change When You Change Your Rate? Csgo

Netsettings were ever a very complex and hot discussed topic in Counter-Strike and there is still a lot of misunderstanding near the netcode in CS:GO. We volition endeavor to enlighten the whole netsettings contend and explain yous which netsettings yous should use for competitive play.

Recommended Netsettings

Straight to the indicate – these are our recommended netsettings for usual high-speed internet (DSL6000+). They are optimized for competitive play on 128 tick servers. Yet, your netsettings volition be automatically adapted to Valve'due south official Matchmaking servers, which merely utilize 64 tick.
rate "786432" cl_cmdrate "128" cl_updaterate "128" cl_interp "0" cl_interp_ratio "1"

Explaination of the config variables

charge per unit "786432" (def. "196608")

Max. bytes/sec the host can receive data

cl_cmdrate "128" (def. "64", min. x.000000 max. 128.000000)

Max. number of command packets sent to server per 2nd

cl_updaterate "128" (def. "64")

Number of packets per 2nd of updates yous are requesting from the server

cl_interp "0" (def. "0.03125", min. 0.000000 max. 0.500000)

Sets the interpolation amount (bounded on low side by server interp ratio settings)

cl_interp_ratio "one" (def. "2.0")

Sets the interpolation corporeality (final amount is cl_interp_ratio / cl_updaterate)

In September 2016 Valve updated some of the networking aspects of CS:GO and increased the default charge per unit from "80000" to "196608", which will accommodate users with internet connections of 1.five Mbps or amend. They as well increased the max rate setting up to "786432" for users with at least half dozen Mbps. If yous have vi Mbps or more than bandwidth, you should use the new max rate of "786432" to let CS:GO to laissez passer more traffic from the server to your system.

Old versus New Hitboxes

On 15th September 2015 Valve released an update, which improved the old player skeleton and hitbox system in CS:GO. They likewise replaced all player animations to get rid of some really annoying bugs. The reddit user whats0n took a look into the model files and published a very nice image comparison between the sometime and new hitbox system.

CSGO hitbox comparison T

CSGO hitbox comparison CT

Equally you lot can come across, the new hitboxes are capsule-based. The capsules are able to fill up out the player models slightly better, so information technology's a little fleck easier to hit the enemy. Together with the new role player skeleton and the reworked animations, this update also fixed a bunch of annoying bugs e.g. the hitbox bug while someone was jumping, planting the bomb or moving on a ladder.

Official explaination of the new net_graph

The following questions were answered by Vitaliy Genkin (Valve employee) via csgomailinglist, after they decided to restrict all net_graph values above 1 in April 2014.

csgo_new_netgraph

What does the value represented past "sv" mean now?
Value of "sv" shows how many milliseconds server simulation step took on the last networked frame.

What does the +- next to the sv represent?
Value following sv +- shows standard deviation of server simulation stride duration measured in milliseconds over the history of last l server frames.

What does the current value for var stand for?
Value for sv var when server functioning is meeting tickrate requirements represents the standard deviation of accurateness of server Bone nanosleep function measured in microseconds over the history of last 50 server frames. The latest update relies on it for efficiently sleeping and waking upwards to outset next frame simulation. Should commonly be fractions of milliseconds. Value for client var near fps cyberspace graph display is showing standard departure of client framerate measured in milliseconds over the history of last 1000 client frames. By using fps_max to restrict customer rendering to maintain a consistent fps client can accept framerate variability at a very low value, only go on in mind that system processes and 3rd party software tin can influence framerate variability too.

Originally, it was considered respectable to take a var of less than 1, reasonable to have information technology fasten as high every bit ii, only pretty much horrible to take a variance remain above 2 for any length of time. What would be the equivalent values for the three new measurements (sv, +-, and var)?
For a 64-tick server as long equally sv value stays mostly below xv.625 ms the server is meeting 64-tick rate requirements correctly. For a 128-tick server every bit long equally sv value stays mostly below 7.viii ms the server is meeting 128-tick rate requirements correctly. If standard difference of frame start accurateness exceeds fractions of millisecond then the server OS has lower slumber accuracy and yous might want to keep sv simulation duration within the max duration minus OS sleep precision (e.g. for a 64-tick Windows server with sleep accurateness variation of i.five ms y'all might want to brand sure that server simulation doesn't accept longer than 15.625 minus ane.5 ~= 14 ms to ensure best experience).

Simplified & Summarized

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

What is the difference between 64 and 128 tick servers?

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

Of grade this is very simplified, but to understand the reward of a higher tickrate, you firstly need to empathise the basics of multiplayer networking within the Source Engine. Valve is running an official wiki with some skilful explanations how the netcode works in CS:GO. Nosotros could summarize this data with our own words, but we feel like you should read the official words from Valve:

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

The customer and server communicate with each other past sending minor data packets at a high frequency. A client receives the current earth 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 non between each other (like in a peer-to-peer awarding).

Network bandwidth is express, so the server tin't send a new update packet to all clients for every unmarried earth modify. Instead, the server takes snapshots of the current earth state at a constant charge per unit and broadcasts these snapshots to the clients. Network packets take a certain corporeality of time to travel between the customer and the server (i.e. the ping time). This means that the customer fourth dimension is e'er a petty bit backside the server time. Furthermore, client input packets are besides delayed on their way back, and so the server is processing temporally delayed user commands. In addition, each client has a different network filibuster which varies over time due to other background traffic and the client's framerate. These fourth dimension differences between server and client causes logical bug, becoming worse with increasing network latencies. In fast-paced action games, even a filibuster of a few milliseconds can cause a laggy gameplay feeling and brand information technology difficult to hit other players or interact with moving objects. Besides bandwidth limitations and network latencies, data tin can become lost due to network packet loss.

If you are interested to dip even deeper into the netcode of CS:Get, nosotros highly recommend you to lookout the "Netcode Assay" from Battle(non)sense. He greatly visualized the nuts of a netcode in online games and also measured the delays in CS:GO and compared them to other games.