---
title: "Fix: Server FPS Stuck at 100 / Low Server FPS on Linux"
excerpt: "Why hlds_linux caps at 100 server FPS, how sys_ticrate, the kernel timer and -pingboost interact, and the safe ways to raise and hold a stable server FPS."
category: "errors"
tags: "fps, sys_ticrate"
image: ""
read_time: "8 min read"
---
<p>You check <code>stat</code> or an FPS plugin and the server sits at exactly 100 FPS no matter what you set. Server FPS on the Half-Life engine is how many times per second the server simulates and sends updates; a server pinned at 100 feels laggier than its rate settings suggest, and hitreg suffers. On Linux the cap comes down to how the engine sleeps between frames and how you launch it. Here is how to raise it without setting the CPU on fire.</p>

<h2>1. See what you actually have</h2>
<p>On the server console:</p>
<pre>stat
sys_ticrate</pre>
<p><code>stat</code> prints the current server FPS. <code>sys_ticrate</code> is the requested maximum. If <code>sys_ticrate</code> is 100 (or unset), 100 is your ceiling by design — the fix is to raise it and to make the engine able to reach it.</p>

<h2>2. Raise sys_ticrate</h2>
<p>Set it on the launch line or in <code>server.cfg</code>. A common target is 500 or 1000:</p>
<pre>sys_ticrate 1000</pre>
<p>Or on the command line:</p>
<pre>./hlds_run -game cstrike -pingboost 0 -sys_ticrate 1000 \
  -ip 0.0.0.0 -port 27015 +maxplayers 20 +map de_dust2</pre>
<p>Raising the number alone is often not enough on stock HLDS, because how the engine waits between frames — the pingboost mode — decides whether it can actually hit that rate.</p>

<h2>3. Understand -pingboost and the timer</h2>
<p>Stock <code>hlds_run</code> supports <code>-pingboost 1/2/3</code>, which switch the sleep strategy between frames. Higher pingboost modes busy-wait more aggressively and can raise FPS, but they burn CPU and some modes are unstable on modern kernels. This is the classic trade: a higher, steadier FPS costs CPU. Test each mode and watch both <code>stat</code> and host CPU:</p>
<pre>-pingboost 1
-pingboost 2
-pingboost 3</pre>
<p>Do not cargo-cult a mode from a forum — measure on your kernel. If a mode makes FPS erratic or spikes CPU to 100% for no players, it is the wrong mode for your box; see <a href="/tutorials/fix-hlds-100-cpu">the 100% CPU guide</a>.</p>

<h2>4. Run ReHLDS and let it hold FPS properly</h2>
<p>The clean answer in 2026 is <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>. Its frame timing is far better than stock HLDS and it holds a requested FPS with much less CPU than pingboost hacks. On ReHLDS, <code>sys_ticrate 1000</code> with the default sleep strategy typically gives a stable 1000 FPS on a modern core, and there are ReHLDS cvars to tune the sleep behaviour if needed. If you care about server FPS at all, the engine swap is the highest-leverage change you can make.</p>

<h2>5. Do not confuse server FPS with client updates</h2>
<p>Server FPS caps how often the server ticks; it interacts with <code>sv_maxupdaterate</code>. There is no point running 1000 server FPS with <code>sv_maxupdaterate 20</code> — the updates a client receives are bounded by the rate cvars. Keep them coherent:</p>
<pre>sys_ticrate 1000
sv_maxupdaterate 101
sv_maxrate 25000</pre>

<h2>6. Rule out the host and the timer</h2>
<p>On a shared or heavily oversubscribed VPS you can set <code>sys_ticrate 1000</code>, run ReHLDS, and still not hold it — because the hypervisor is not giving your vCPU consistent time. Two quick checks separate "my config is wrong" from "my host is the problem". First, watch steal time on the host:</p>
<pre>top    # look at the %st (steal) column</pre>
<p>Non-trivial steal means the hypervisor is scheduling you off the CPU, and no cvar fixes that — you need a better plan or a dedicated core. Second, confirm the measurement itself: idle FPS and loaded FPS are different worlds, so always judge with players on. A server that holds 1000 empty and 1000 with a full match on a dedicated box is genuinely healthy; the same config on a busy VPS is at the mercy of neighbours.</p>

<h2>Common errors</h2>
<ul>
<li><strong>FPS stuck at exactly 100</strong> — <code>sys_ticrate</code> is at its default; raise it and confirm the engine can reach it.</li>
<li><strong>Raised sys_ticrate, FPS did not move</strong> — stock HLDS sleep strategy is capping you. Try a <code>-pingboost</code> mode or, better, move to ReHLDS.</li>
<li><strong>High FPS but CPU pinned at 100%</strong> — an aggressive pingboost busy-wait. Expected trade-off; drop the mode or switch engines. See <a href="/tutorials/fix-hlds-100-cpu">the CPU fix</a>.</li>
<li><strong>FPS swings wildly under load</strong> — the box is oversubscribed (shared VPS with noisy neighbours) or the kernel timer is coarse. A dedicated core and ReHLDS fix most of this.</li>
</ul>

<h2>Verification</h2>
<p>With players on the server (idle FPS is not representative), run repeatedly:</p>
<pre>stat</pre>
<p>You want the FPS to sit at or near your <code>sys_ticrate</code> target and stay there through a full round, while host CPU stays reasonable for the player count. A number that reads 1000 when empty but collapses to 300 under 20 players means you are CPU-bound — reduce pingboost aggressiveness, move to ReHLDS, or get a faster core. Watch it for a whole map, not a single sample.</p>