ReHLDS Performance Cvars That Actually Matter

The biggest performance win from ReHLDS is the rewritten engine itself — more accurate frame timing and a faster network path than Valve's original. On top of that it exposes a set of sv_rehlds_* cvars that do not exist on stock HLDS. Most of them are correctness or hardening switches rather than raw speed knobs, but several directly affect how the server behaves under load and under attack, which is what "performance" means once real players show up. This guide covers the ones worth setting and, just as important, how to introduce them safely.

This assumes you already run ReHLDS. If not, do the install first — none of these commands exist on the Valve engine, and setting them there is a silent no-op.

1. Confirm you are actually on ReHLDS

rehlds_version

Stock HLDS answers Unknown command: rehlds_version. ReHLDS prints a version string. If you get the "unknown command" reply, the engine was not replaced and nothing below applies.

2. Timing and tick rate

ReHLDS holds a high sys_ticrate far more reliably than stock HLDS, which is the whole reason people chase it for FPS. Set the target as usual on the launch line:

./hlds_run -game cstrike -pingboost 1 +sys_ticrate 1000 \
  +map de_dust2 +maxplayers 20 +sv_lan 0

Then measure under load with stats as described in the stable-FPS guide. On ReHLDS a 1000 target is realistic where stock HLDS would jitter.

3. Anti-flood cvars protect FPS under attack

A server does not only slow down from too many honest players — it slows down, or dies, when someone floods it with movement or string commands. ReHLDS ships rate limiters for exactly this. Add them to server.cfg:

// limit per-client command flooding
sv_rehlds_stringcmdrate_max_avg 80
sv_rehlds_stringcmdrate_max_burst 200

// limit connections from a single address
sv_rehlds_maxclients_from_single_ip 5

These keep one abusive client from consuming a disproportionate share of the single server thread. Treat the numbers as starting points and read your ReHLDS build's own cvar list — exact names and defaults change between releases, and inventing a cvar just gets you a silent no-op.

4. Network and download behaviour

// force the max client download rate the engine allows
sv_rehlds_force_dlmax 1

// do not push the mapcycle to clients
sv_rehlds_send_mapcycle 0

// use engine-local gametime (fixes some timing-sensitive bugs)
sv_rehlds_local_gametime 1

sv_rehlds_force_dlmax 1 smooths out custom-content downloads on connect, which is where a lot of "stuck at connecting" reports come from; pair it with a proper FastDL setup. sv_rehlds_local_gametime 1 is a correctness fix worth having on.

5. Introduce them one batch at a time

This is the part people skip and regret. Some hardening cvars interact badly with old plugins that build raw network messages by hand. Turn on one small group, restart, and watch the log through a map change and a few connects:

rcon sv_rehlds_local_gametime 1
// restart, play a map, watch the console
rcon sv_rehlds_force_dlmax 1
// restart, watch again

If the server starts crashing right after you enable a batch, you have found the culprit without a bisect. A plugin that dies under a new security cvar usually needs updating, not the cvar disabling forever.

6. What ReHLDS cvars will not do

No sv_rehlds_* cvar turns a saturated core into a fast one. If stats shows the core at 100%, the answer is a faster CPU, fewer or lighter plugins, or a lower sys_ticrate — not another cvar. Likewise, the rate window that players actually experience is governed by sv_maxrate and sv_maxupdaterate, which are engine-agnostic and matter regardless of ReHLDS.

Common errors

• Unknown command: sv_rehlds_... — you are not on ReHLDS, or the cvar name is wrong/renamed in your build. Verify with rehlds_version and read the shipped cvar list.
• Server crashes right after enabling a hardening cvar — an old plugin sends malformed messages the cvar now rejects. Enable in small batches to find it, then update the plugin.
• Set a cvar, nothing changed — a misspelled cvar is a no-op with no error in older builds. Copy the exact name from the release notes.
• FPS unchanged after tuning — you were CPU-bound all along. Measure first; the fix is hardware or plugin load, per the 100% CPU guide.

Verification

After each batch, confirm rehlds_version still answers, the server reaches a map, and meta list (if Metamod is loaded) still shows every plugin as RUN. Load the server and re-measure FPS with stats to prove the timing held. The goal is a server that is not just fast when empty but stays fast and stable when someone tries to abuse it.