sv_maxrate, sv_maxupdaterate and sv_minupdaterate: Correct Values

Client-side rate, cl_updaterate and cl_cmdrate only ever matter within the limits the server imposes. A player can ask for cl_updaterate 101 all day; if your sv_maxupdaterate is 60, they get 60. These four server cvars — sv_maxrate, sv_minrate, sv_maxupdaterate, sv_minupdaterate — are the ceiling and floor for the whole server, and getting them right is the difference between a smooth 100-tick feel and a room full of people complaining about choke.

1. What each cvar controls

There is no sv_maxcmdrate; the server does not cap how many command packets a client sends the same way, though cl_cmdrate effectively tops out around the update rate in practice.

2. Sensible values for a public server

For a normal internet server on ReHLDS or HLDS, put these in server.cfg:

sv_maxrate 25000
sv_minrate 15000
sv_maxupdaterate 101
sv_minupdaterate 30
sv_timeout 60

sv_maxupdaterate 101 lets well-connected players run the full 100-tick experience. sv_minupdaterate 30 keeps a player on a poor connection from dropping their update rate so low that they become impossible to hit fairly. The rate floor of 15000 does the same job for bandwidth.

3. About the number 100000

The 25th Anniversary update in 2023 raised the default and maximum rate the client uses (older builds effectively clamped it around 25000–20000). On a modern engine you can safely allow more headroom:

sv_maxrate 100000
sv_minrate 25000

This is worth doing on ReHLDS with mostly modern clients, because it lets high-updaterate players actually receive the data those updates need without hitting a bandwidth wall. If you still serve a lot of old or steam_legacy clients, keep sv_maxrate nearer 25000 — they will not benefit from more and you save bandwidth.

4. Unlimited rate (sv_maxrate 0) and why to avoid it

sv_maxrate 0 removes the cap entirely. On a LAN that is fine. On a public server it is a mistake: it lets a client demand enormous bandwidth per tick, and it removes your only lever against a client that misconfigures itself into flooding the connection. Always set a real ceiling.

5. How the client values interact with yours

Every client value is clamped into your window. If a player sets cl_updaterate 101 and your sv_maxupdaterate is 60, they run at 60. If they set rate 100000 and your sv_maxrate is 25000, they run at 25000. This is why players sometimes insist "my rates are perfect" while the server serves them something else entirely — the ceiling wins. The full client side is in best rate, cl_updaterate and cl_cmdrate settings.

6. Apply without a full restart

These cvars can be changed live over RCON, but connected clients renegotiate their rate on the next connection, so the clean way is:

rcon sv_maxupdaterate 101
rcon sv_minupdaterate 30
rcon sv_maxrate 25000
rcon sv_minrate 15000

Then change the map, or have players reconnect, so everyone picks up the new window.

Common errors

• Players stuck at low update rate — sv_maxupdaterate is set low (often left at a default like 30 or 60). Raise it to 101.
• Everyone chokes at once — sv_maxrate is too low for the update rate you allow. High update rate plus a tight rate cap means the server cannot fit the data and clients show choke. Raise sv_maxrate or lower sv_maxupdaterate together. See choke and loss on the scoreboard.
• One player abuses a tiny rate — without sv_minrate/sv_minupdaterate, a client can drop to values that make their movement jerky and hard to hit. Set the floors.
• Values do not stick — something later in your config (a mod's cfg, game.cfg, or a plugin) overwrites them. Grep your configs and check execution order; related symptoms in server.cfg not executing.

Verification

Connect a client, set cl_updaterate 101 and rate 100000, then open net_graph 3 and watch the update rate the server actually delivers. It should sit at your sv_maxupdaterate with low choke. From the server, rcon stats should show healthy Out bandwidth without the FPS collapsing. If choke appears the moment you raise the update rate, your sv_maxrate is the limiter — raise it and retest.