Fix: sv_maxrate / sv_maxupdaterate Settings Ignored

You set sv_maxrate and sv_maxupdaterate high so modern clients can run smooth 100-tick netcode, but players still cap at a low rate or their net_graph shows a modest updaterate no matter what you type. These cvars are frequently "ignored" for concrete reasons: some do not exist on stock HLDS, some are clamped by their min counterparts, and some are being reset later in your config load order. Here is how the rate cvars actually behave.

1. Know which cvars are stock and which are not

This is the crux. On stock Valve HLDS, sv_maxrate and sv_minrate exist, but the fine-grained update-rate ceilings people expect — sv_maxupdaterate, sv_minupdaterate, sv_maxcmdrate — come from ReHLDS / ReGameDLL_CS. On a plain HLDS box, setting sv_maxupdaterate 101 is a silent no-op: the cvar may not be honoured, and clients are capped by the engine's own defaults instead. If your update-rate ceiling is being ignored, the first question is whether you are even running an engine that implements it. Install ReHLDS (and ReGameDLL) to get real control over these.

2. Set the full, consistent block

Rates work as min/max pairs. If you set a max but leave the min at a value that clamps clients, you get surprising results. Set the whole block coherently in server.cfg:

sv_maxrate 25000
sv_minrate 5000
sv_maxupdaterate 101
sv_minupdaterate 20
sv_maxcmdrate 101

A client's effective rate is clamped into the [min, max] window. If sv_minupdaterate is left high, low-rate clients are forced up; if sv_maxupdaterate is low or unimplemented, high-rate clients are pulled down and it looks like your 101 was ignored. Set both ends deliberately.

3. Watch the config execution order

A classic "ignored" case is that your value is applied, then overwritten later. ReGameDLL ships a game.cfg, AMX Mod X execs its own configs, and any of these can re-set a rate cvar after your server.cfg runs. If sv_maxrate reverts, something is exec-ing after you. Read the value back at runtime, long after boot:

sv_maxrate

If the console shows a different number than you set, hunt for the later config that overrides it — check game.cfg, amxx.cfg, and any map-specific config. Put your authoritative rate values where nothing runs after them, or in the config that runs last.

4. Remember the client still chooses within your window

The server cvars are ceilings and floors, not assignments. A client running cl_updaterate 30 gets 30 even if your max is 101 — you cannot force a client up beyond what it requests except via the min floor. So "players are at 30" with sv_maxupdaterate 101 is not the server ignoring you; it is the client asking for 30. Raise the floor to lift lazy clients:

sv_minupdaterate 60

Now a client requesting less than 60 is pulled up to 60. Tell players to set rate 25000; cl_updaterate 101; cl_cmdrate 101 to actually use the headroom you provided.

5. Rule out an old engine cap

Very old HLDS builds cap sv_maxrate lower than modern play expects, and some hosts pre-set a low sv_maxrate in a base config you did not write. If sv_maxrate will not go above, say, 20000 however you set it, you are likely on an outdated engine or a host template — updating to a current ReHLDS build removes those artificial ceilings and is the same move that stabilises your server FPS.

Troubleshooting

• sv_maxupdaterate does nothing — you are on stock HLDS where it is not implemented. Move to ReHLDS/ReGameDLL.
• Value reverts after boot — a later config (game.cfg, amxx.cfg, map cfg) overrides it. Read it back with sv_maxrate and fix the exec order.
• Clients stuck at a low updaterate — they are requesting it. Raise sv_minupdaterate and have players set cl_updaterate 101.
• sv_maxrate refuses to go high — an outdated engine or a host base config caps it. Update the engine.
• Only some players benefit — the others' rate/cl_updaterate are low. Server cvars set the window, not the client's choice.

Verification

Read every rate cvar back in the console with no argument and confirm each holds the value you set — do this well after startup so a late config would already have overridden it. Then have a player set high client rates, join, and run net_graph 3: the reported updaterate should reach your ceiling and hold. If the server cvars read correctly and a well-configured client hits 101, the rates are being honoured. Lock the final block into the last-executing config so nothing quietly resets it.