Choke and loss both make the game feel rubbery, but they are opposite problems. Choke means the server wants to send more updates than the configured rate allows, so it holds packets back — a configuration problem you own. Loss means packets are genuinely disappearing on the wire — a network problem. Fixing them requires telling them apart first, and net_graph does exactly that.
1. Read net_graph to identify which one
Have an affected player enable the graph:
net_graph 3 net_graphpos 2
The graph shows separate choke and loss counters. Non-zero choke with zero loss is a rate-cap problem. Non-zero loss is packets dropped in transit. They can occur together, but treat them separately.
2. Fix choke: raise the server rate caps
Choke appears when a client's requested update rate exceeds what the server will deliver, or when sv_maxrate is too low for the data volume. In server.cfg:
sv_maxrate 25000 sv_minrate 15000 sv_maxupdaterate 101 sv_minupdaterate 30
The old sv_maxrate 9999 / sv_maxupdaterate 30 defaults choke instantly on a full, busy server. 25000 bytes/s and 101 updates are sane modern values.
3. The FPS-vs-updaterate rule
A server cannot send more updates per second than it runs frames per second. If sv_maxupdaterate is 100 but the server runs at 64 FPS, everyone chokes down to ~64 no matter what. Confirm FPS with stats in the console and, on Linux, raise it:
sys_ticrate 1000 fps_max 1000
Rule of thumb: server FPS should be at least equal to sv_maxupdaterate. See the high-ping guide — low FPS causes both choke and ping.
4. Set sane client rates
Client cvars must fit inside the server caps. A good client baseline:
rate 25000 cl_updaterate 101 cl_cmdrate 101
If a client sets cl_updaterate 128 against a server capped at 101, the server clamps it and the extra shows as choke on that player only. You can standardise this server-side with sv_maxupdaterate so no client can exceed it.
5. Fix loss: it is the network
Loss is not fixable with cvars. Have the player run a route trace to find where packets die:
mtr YOUR_SERVER_IP # Linux pathping YOUR_SERVER_IP # Windows
Loss that starts at a specific hop and continues to the end is a real drop point — the player's ISP, a transit provider, or your host. Loss only on the final hop is usually the server host or a saturated uplink; open a ticket with the trace. Also check the server is not itself dropping packets from an overloaded NIC or an iptables rate limit you forgot about.
6. MTU and fragmentation
Consistent low-level loss for players on certain connections (PPPoE, some mobile links) can be MTU fragmentation. This is edge-case, but if a subset of players always show 1–2% loss while LAN players show none, MTU is a suspect. It is a client-side / ISP concern; there is no server cvar that fixes a fragmented path.
7. A reference rate configuration
For a modern public server, these are the server and client values that eliminate choke for the vast majority of connections. Server side, in server.cfg:
| Cvar | Value | Purpose |
|---|---|---|
sv_maxrate | 25000 | Max bytes/s per client |
sv_minrate | 15000 | Floor so nobody starves themselves |
sv_maxupdaterate | 101 | Cap on updates/s the server sends |
sv_minupdaterate | 30 | Floor for playable prediction |
fps_max / sys_ticrate | 1000 | Server FPS ceiling (Linux) |
Client side, a player suggests: rate 25000, cl_updaterate 101, cl_cmdrate 101. Because the server clamps to its own caps, no client can force values that would choke the whole server — the caps are the real control.
Common errors
- Whole server chokes at once —
sv_maxratetoo low or server FPS belowsv_maxupdaterate. Fix caps and FPS. - One player chokes, rest fine — that client requested a rate above the server cap; harmless, or lower their
cl_updaterate. - Loss but zero choke — packet loss on the path. cvars will not help; trace the route.
- Choke spikes only on smoke/flash-heavy rounds — data burst exceeding
sv_maxrate. Raise it to 25000.
Verification
After raising the caps and confirming FPS, have the same player watch net_graph 3 through a full round. Choke should sit at 0 during normal play and only tick up briefly during heavy grenade spam. If loss is still non-zero, the problem was never choke — it is the network, and the route trace is your evidence for the host ticket.
