How to Reduce Lag on a Counter-Strike 2 Server

What “lag” means on a CS2 server

When players say “the server is lagging”, they can mean several different failures that need different fixes. The fastest way to sort it out is to match the symptom to the place you should look first.

Use this flow to separate server trouble from network trouble from one player’s machine before you touch the cfg.

Sub-tick, 64 tick and the 15.6 ms budget

CS2 uses sub-tick updates. In plain English, the server records the exact instant that movement starts, a shot is fired or a grenade is thrown, so actions are judged on when they really happened instead of being rounded up to the next whole tick.

That does not mean the world simulation runs constantly. The world still updates in fixed ticks, and current CS2 dedicated servers run at 64 ticks per second. One tick is roughly 15.6 ms, so every server frame has to fit all of its work inside that budget: player input, movement, grenade physics, entity updates, plugin hooks and the snapshots sent to clients.

If that work takes longer than roughly 15.6 ms, the server overruns the tick budget. That shows up as Svms rising, +-ms becoming spiky, and eventually server FPS dropping below 64. Once that happens, players feel delayed updates, rubber-banding or unstable hit registration even if their raw ping looks fine.

This is also why chasing 128 tick on CS2 is a dead end. There is no supported 128-tick CS2 dedicated server, and old CS:GO launch options or copied “128 tick” guides do not change that. The server’s FPS cannot go above the tick rate anyway, so a healthy CS2 server should hold 64, not some bigger number.

The picture below is the useful mental model: not “tick as a marketing number”, but “how much work fits inside one 15.6 ms server frame”.

Measure first: stats, status and the Telemetry HUD

Take readings before you fix anything. One clean reading tells you almost nothing; three readings tell you whether the server degrades under load.

• Empty server: your baseline with nobody stressing the map, plugins or snapshots.
• Quiet moment: a normal round or a light period.
• Worst moment: the exact time players complain, or the busiest point of the session.

stats
status

Read stats like this:

• FPS: server simulation frames per second. It should hold 64. More CPU will not make it show more than 64 because the server tick rate is 64.
• Svms: average milliseconds per server frame. This needs to stay below the per-tick budget of roughly 15.6 ms.
• +-ms: frame-time variance. Spikes here often match the “it hitches every so often” complaints.

status is your per-player check. If one player shows loss while everyone else looks clean, that is usually their route or local network. If many players spike together, think server CPU, server link or a wider network problem.

For player-side checks, CS2 replaced net_graph with the Telemetry HUD. Each player has to enable it on their own PC; you cannot force it from the server. Ask the affected player to enable the network and frame-time views, then tell you what goes bad at the moment they feel lag.

cl_hud_telemetry_ping_show 2
cl_hud_telemetry_frametime_show 2
cl_hud_telemetry_net_misdelivery_show 2
cl_hud_telemetry_serverrecvmargin_graph_show 2

If the server looks clean in stats but one player’s frame-time graph is spiking, you are not looking at a server problem. If their network misdelivery is poor while others are fine, that points to their route, Wi-Fi or VPN rather than your cfg.

Fix tick stability first: if the server misses ticks, nothing else feels right

The biggest payoff usually comes from making the server hold 64 steadily. Choke and bad feel often disappear once the main game thread stops overrunning its budget.

Plugins: isolate before you optimise

Plugins are a common cause because they can do work every tick or block the game thread with database or HTTP calls. When that happens, the server is not “a bit busy”; it is literally waiting on work instead of finishing the current simulation frame. The usual sign is Svms climbing under load, or a hitch repeating at a neat interval such as every 30, 60 or 120 seconds when a timer fires.

The quickest isolation method is halves: move half of the plugins out of game/csgo/addons/counterstrikesharp/plugins/, test again, then keep halving until the culprit is obvious. This is faster than disabling one at a time on a long plugin stack. The trade-off is temporary loss of features while you test, but it is the cleanest way to prove where the stutter comes from.

After every CS2 game update, update Metamod and CounterStrikeSharp as well. Outdated builds often fail in odd ways: not a full crash, just strange hitching, hooks misbehaving or server health getting worse only after the patch.

GOTV, bots and heavy maps

tv_enable 0 removes GOTV work. That reduces per-tick processing and extra traffic, especially on small community boxes where every bit of main-thread time matters. The trade-off is obvious: no GOTV spectators and no TV demos from that server.

Bots are not free. Their AI runs every tick, so a server that is stable in warm-up can fall apart in live rounds if bots are active alongside players and plugins. Lowering or removing bots frees main-thread CPU, but the trade-off is losing bot fill or practice behaviour on servers that rely on it.

Large Workshop maps can also hurt because more entities and map logic mean more work each frame. If one custom map feels bad while stock maps are fine, that is a map problem until proven otherwise. Test the same player count and mode on a lighter map before changing anything else.

Slots and mode must match the CPU

CS2 does most of its server work on one main thread. That means a modest box with several spare cores can still struggle if the main game thread is maxed. More players, more active entities and more snapshots all add work to the same tick budget, so advertising more slots than the CPU can carry is a direct path to unstable 64.

If the server is fine empty and degrades only when the round is busy, reduce slots, simplify the mode or remove expensive add-ons. You are trading peak capacity for consistent simulation, which is nearly always the right trade on scrim, retake and surf communities where “full but stuttering” is worse than “slightly fewer slots but stable”.

Restart if performance degrades over days

If the server starts clean after a fresh boot and becomes worse only after it has been up for a long time, schedule a restart in a quiet hour. This does not fix bad code, but it can clear gradual degradation while you investigate the real cause. The sign that it helped is simple: your worst-case stats readings improve immediately after the restart and stay better for a while.

This matrix is useful when you want to decide what kind of “lag” a setting can actually fix.

Network settings: choke is not the same as loss

Loss means packets were sent and never arrived. That usually points to the route, Wi-Fi, ISP peering or a VPN. Choke means the server had updates but was not allowed, or was not able, to send them. A low rate cap can cause choke, and an overloaded server can cause it too. That is why choke often turns up together with low server FPS.

Start with a clean baseline in server.cfg:

sv_minrate 0
sv_maxrate 0
tv_enable 0
bot_quota 0

sv_minrate 0 and sv_maxrate 0 remove server-side rate caps. The reason this works is simple: a low sv_maxrate copied from an old CS:GO cfg stops the server sending as much data as busy situations need, which creates choke even on a good line. The trade-off is slightly higher bandwidth use at busy moments, but bandwidth is rarely the real limit on a CS2 server.

bot_quota 0 is only for servers that do not need bots. If your mode relies on them, do not copy that line blindly.

Also delete old CS:GO leftovers and any “performance cfg” file you do not fully understand. Old lines such as sv_maxcmdrate and sv_maxupdaterate do not work the way old forum posts claim. If you cannot explain why a cvar is there, remove it and test. If you are unsure a cvar even exists, check it with find <name> in the console.

Client rates matter too. CS2’s client rate default is 786432, shown in the menu as Unrestricted. A player with an ancient autoexec forcing rate 80000 or rate 128000 can create choke for themselves while everybody else is fine. If status shows only one player struggling, ask them to remove old autoexec networking lines before you touch the server again.

Distance still matters more than cfg tweaks. A UK community will generally get the best results from London because raw travel time is lower; nothing in server.cfg can fix a server that is simply too far away. Good settings cannot turn a high-latency route into a low-latency one.

This path diagram helps because loss and choke happen in different places.

For route checks, ask the affected player to test the path to the server IP. On Windows use pathping; on Linux or macOS use mtr.

pathping 203.0.113.10

Read route tests carefully. If loss starts at one hop and continues all the way to the final destination, that is real loss. If a middle hop looks bad but later hops and the destination are clean, that router is probably just ignoring or de-prioritising pings rather than dropping your game traffic.

Resource usage: do not trust the wrong graph

The most common reading mistake is looking at total CPU and deciding the server has plenty left. CS2 server performance is mainly about one main thread. On a machine with several cores, the panel can show a modest overall percentage while the game thread is effectively saturated and your tick time is already slipping. A readable per-core or per-thread graph is far more useful than a single averaged CPU bar.

RAM is usually not the answer to CS2 server lag. The official minimum is 2GB, and once the server has enough memory to run cleanly, missed ticks are far more often a CPU issue than a RAM issue. More RAM can help if the machine is genuinely short of memory, but it does not make the main simulation thread finish faster.

Disk speed matters mostly at map loads and updates. If the complaint is a hitch during map change, slow storage can be involved. If the complaint is rubber-banding in the middle of live rounds, disk is rarely the first suspect. Keep enough storage for the install and updates, but do not expect faster storage to rescue poor in-round tick stability.

Then there is the shared-hosting problem: noisy neighbours. If your server is worse at certain times of day regardless of player count, but fine on the same map and cfg at quieter times, another tenant on the node may be competing for the same hardware. That is not something you tune away in the config.

If you need a refresher on the official baseline for CPU features, RAM, storage and supported operating systems, see these game server hardware requirements. For lag diagnosis, though, remember the order: first tick stability, then rates, then route, and only then bigger hardware.

Symptom → likely cause → first fix

Tune it or upgrade?

Once you have a clean cfg and good measurements, the decision becomes simpler. Upgrade only after you can show that the problem is no longer caused by plugins, bad rates or stale CS:GO leftovers.

Counter-Strike 2 server FAQ

Why is my CS2 server lagging?

Usually because the server is missing its 64-tick frame budget, a bad rate cap is causing choke, packets are being lost on the route, or a player’s PC is stuttering. The only reliable way to tell them apart is to check stats, status and the player’s Telemetry HUD at the exact time the complaint happens.

Can I run a CS2 server at 128 tick?

No, not as a supported CS2 dedicated server setup. CS2 servers currently simulate at 64 ticks per second, and old CS:GO -tickrate advice does not give you a real 128-tick CS2 server. Focus on stable 64 and low frame variance instead.

What is the difference between choke and loss in CS2?

Loss means packets never arrived, which usually points to the route, Wi-Fi, ISP or VPN. Choke means the server had updates but could not, or was not allowed to, send them, usually because of a low rate cap or an overloaded server. Choke often appears together with low server FPS because both come from the same overload.

How do I check server FPS on a CS2 server?

Use the stats command on the server console. The FPS field shows the server simulation rate and should hold 64, while Svms tells you how much time each server frame is taking. Take readings when the server is empty, during normal play and at the worst moment, not just once after a restart.

Will more RAM stop my CS2 server lagging?

Usually not. CS2 needs at least 2GB to run, but in-round lag is more often caused by the main CPU thread missing its tick budget than by memory. Extra RAM helps only if the machine is genuinely short of memory; it does not make the server simulate ticks faster.

More server lag guides

Our Counter-Strike 2 host comparison, plus lag guides for other games.