---
title: "Eliminating Choke on Your Server (sv_maxupdaterate Math)"
excerpt: "What choke actually is, the exact relationship between cl_updaterate, sv_maxupdaterate, sv_maxrate and server fps, and the config that stops the yellow \"choke\" line on net_graph."
category: "optimization"
tags: "choke, rates"
image: ""
read_time: "8 min read"
---
<p>Choke is the single most misdiagnosed netcode symptom in CS 1.6. When players see the yellow <code>choke</code> counter climb on <a href="/tutorials/cs16-net-graph-guide">net_graph 3</a>, it does <strong>not</strong> mean their connection is bad &mdash; it means <em>your server could not send updates as fast as their client asked for them</em>. Choke is a server-side back-pressure signal, and it is governed by a small set of cvars whose math is worth getting exactly right.</p><h2>1. Understand the update contract</h2><p>Each client requests a snapshot rate with <code>cl_updaterate</code> (how many world updates per second it wants) and <code>cl_cmdrate</code> (how many command packets it sends up). The server answers with at most <code>sv_maxupdaterate</code> updates per second, and each update is capped in size by <code>sv_maxrate</code> bytes/sec. Choke appears when the client asks for more updates than the server is configured &mdash; or able &mdash; to emit. If a client sets <code>cl_updaterate 101</code> but you run <code>sv_maxupdaterate 60</code>, the client is silently capped at 60 and the difference registers as choke on its net_graph.</p><h2>2. Set the server ceiling correctly</h2><p>The core fix is raising the server's update ceiling and its rate ceiling together. On a modern <a href="/tutorials/hlds-vs-rehlds-explained">ReHLDS</a> box:</p><pre>sv_maxupdaterate 100
sv_minupdaterate 20
sv_maxrate 25000
sv_minrate 5000</pre><p>Raising <code>sv_maxupdaterate</code> to 100 or 101 lets clients that request high update rates actually receive them. <code>sv_maxrate 25000</code> gives each client enough bytes/sec headroom that a full snapshot fits without being truncated. Setting <code>sv_minrate 5000</code> floors low-rate clients so they stop starving. See <a href="/tutorials/sv-maxrate-maxupdaterate-values">recommended maxrate/maxupdaterate values</a> for the full table.</p><h2>3. The math that actually matters</h2><p>Choke is not just a cvar mismatch &mdash; it is also a physics limit. The server can only send an update on a frame boundary. If your server runs at 100 fps, it produces at most 100 frames per second, so it can emit at most 100 updates per second no matter what <code>sv_maxupdaterate</code> says. This is the link people miss: <strong>sv_maxupdaterate is a ceiling, server fps is the engine</strong>. To deliver 100 updates/sec you must run a stable ~1000 fps server (or at minimum a rock-solid 100), because a server dipping to 40 fps under load can only send 40 updates/sec and every high-rate client chokes. Confirm your real fps with the console and the guide at <a href="/tutorials/measure-server-fps">measuring server fps</a>:</p><pre>stats</pre><p>The <code>fps</code> column must comfortably exceed your <code>sv_maxupdaterate</code>. If it does not, fix fps first &mdash; see <a href="/tutorials/stable-1000-fps-linux-server">stable 1000 fps</a> and <a href="/tutorials/sys-ticrate-truth">the sys_ticrate truth</a>.</p><h2>4. Size sv_maxrate against player count</h2><p>Each update carries entity deltas; the more players and entities, the larger each snapshot. With <code>sv_maxrate</code> too low, the update does not fit the byte budget, gets split, and the client chokes waiting for the rest. As a rough guide, <code>25000</code> comfortably covers a full 20&ndash;24 player server; a busy 32-slot server benefits from <code>30000</code> or higher, or <code>0</code> (unlimited) on a well-provisioned ReHLDS box where you trust bandwidth. Do not set unlimited on a bandwidth-constrained VPS &mdash; you will trade choke for loss.</p><h2>5. Push clients toward matching rates</h2><p>You can floor client behaviour but not force it. Advise your players to run:</p><pre>cl_updaterate 100
cl_cmdrate 100
rate 25000</pre><p>and point them at <a href="/tutorials/cs16-best-client-rates">the best client rates guide</a>. On ReHLDS, <a href="/tutorials/rehlds-performance-cvars">the ReHLDS performance cvars</a> add tuning that reduces jitter further.</p><h2>Common errors</h2><ul><li><strong>Yellow <code>choke</code> climbs even on a LAN</strong> &mdash; server fps is below sv_maxupdaterate. The engine cannot emit updates it never rendered. Fix fps.</li><li><strong>Choke only on full server</strong> &mdash; <code>sv_maxrate</code> too low for the snapshot size at high player counts. Raise it.</li><li><strong>Client sets cl_updaterate 101 but net_graph shows ~60 updates</strong> &mdash; <code>sv_maxupdaterate</code> is capping them at 60. Raise the server ceiling.</li><li><strong>Choke swaps to loss when you raise sv_maxrate</strong> &mdash; you exceeded real bandwidth; the packets now drop instead of queue. Balance the two.</li><li><strong>Config looks right but choke persists</strong> &mdash; an AMXX config or <code>game.cfg</code> re-sets the cvars after <code>server.cfg</code>. Trace execution order and read the values back.</li></ul><h2>Verification</h2><p>Join your own server and open <code>net_graph 3</code>. The <code>choke</code> counter should read <code>0</code> under normal play with a client running <code>cl_updaterate 100</code>. Read the ceilings back in the console:</p><pre>sv_maxupdaterate
sv_maxrate
stats</pre><p>Confirm <code>sv_maxupdaterate</code> is 100/101, <code>sv_maxrate</code> is at least 25000, and the <code>fps</code> from <code>stats</code> is above your updaterate with a full server. If choke only appears at peak population, walk the <a href="/tutorials/fix-choke-loss-scoreboard">choke and loss on the scoreboard</a> guide, which covers the same signals as they show up mid-match.</p>