Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent d1c8959a84
commit 254c516cc9a897c31f0d2b16e0c88b6a8d9fa6cf
2 changed files
with 19 additions and 0 deletions
best-cpu-for-cs16-server/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Best CPU for a CS 1.6 Server (Single-Thread Wins)" | |
| 3 | +excerpt: "Why per-core clock speed and IPC decide CS 1.6 server performance far more than core count, and how to read a CPU spec sheet for a GoldSrc host." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "cpu, hardware" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The most common hardware mistake in CS 1.6 hosting is buying cores. A 32-core server CPU looks impressive and will run a <em>single</em> CS 1.6 server worse than a cheap desktop chip with a high clock. The reason is architectural and non-negotiable: HLDS and <a href="/tutorials/hlds-vs-rehlds-explained">ReHLDS</a> are essentially <strong>single-threaded per instance</strong>. One server process does its work on one core, and that core's speed is your ceiling.</p><h2>1. Why single-thread performance is the whole game</h2><p>A CS 1.6 server runs its simulation loop — physics, hit registration, entity updates — on one thread. It cannot spread that loop across cores; there is no parallelism to exploit. So the numbers that determine how high your <a href="/tutorials/measure-server-fps">server FPS</a> can climb and how it holds under load are:</p><ul><li><strong>Clock speed</strong> — raw GHz on the core the server runs on.</li><li><strong>IPC (instructions per clock)</strong> — how much a newer architecture does per GHz. A modern 3.5 GHz core beats an ancient 3.5 GHz core meaningfully.</li></ul><p>Core count does nothing for one server. This is <a href="/tutorials/is-hlds-single-threaded">the single-thread reality</a>, and no cvar changes it.</p><h2>2. When core count actually helps</h2><p>Cores matter for exactly one thing: running <strong>many</strong> server instances. Each server pins one core, so an 8-core chip can comfortably host several independent servers, one core each, without them fighting. If your plan is a hosting box with a dozen servers, core count buys capacity — but each individual server is still only as good as one core's single-thread speed. See <a href="/tutorials/multiple-cs16-servers-one-vps">running multiple servers on one box</a> for how to pack them.</p><h2>3. How to read a spec sheet</h2><p>Ignore the marketing core count and look for single-thread signal:</p><ul><li><strong>Single-thread benchmark scores</strong> — PassMark's "Single Thread Rating" and Cinebench single-core are good proxies. Higher is directly better for one server. (Compare the actual current scores yourself; do not trust a number someone quotes from memory.)</li><li><strong>Base and boost clock</strong> — a server pinned to a core runs it continuously, so sustained all-core-ish boost behaviour matters more than a peak single-core boost the chip only holds briefly.</li><li><strong>Generation</strong> — a newer architecture at the same GHz wins on IPC.</li></ul><p>A high-clock desktop-class chip typically posts a far better single-thread score than a many-core server chip clocked low for density, which is exactly why budget game hosts often run desktop CPUs.</p><h2>4. The clock/density trade-off in real CPUs</h2><p>Server CPUs are designed for throughput: lots of cores at modest clocks, tuned for many parallel workloads. Game servers want the opposite — the highest possible speed on one core. That is why a chip marketed for gaming/workstation use, with fewer cores at higher clocks, is usually the better CS 1.6 host per server. If you are renting, ask the host for the exact CPU model and look up its single-thread rating rather than accepting "8 vCPU" as a quality signal — on a <a href="/tutorials/dedicated-vs-vps-performance">VPS the vCPU count tells you nothing about the core's speed or whether you even get it</a>.</p><h2>5. Pin the server to a fast core</h2><p>Buying the fast CPU is half the job; make sure the server actually runs on the fast core and stays there. Use <a href="/tutorials/cpu-affinity-taskset-hlds"><code>taskset</code> to pin the instance</a> and set the <a href="/tutorials/cpu-governor-performance">CPU governor to <code>performance</code></a> so the core does not clock down between packets. A great CPU left on the <code>ondemand</code> governor throws away part of its single-thread advantage to frequency ramp latency.</p><h2>Common mistakes</h2><ul><li><strong>Buying core count for one server</strong> — 32 cores do not help a single-threaded process. Buy clock and IPC.</li><li><strong>Trusting "vCPU" numbers</strong> — a vCPU count says nothing about the underlying core speed or steal. Ask for the chip model.</li><li><strong>Comparing GHz across generations</strong> — IPC differences mean equal GHz is not equal performance; use a single-thread benchmark.</li><li><strong>Great CPU, default governor</strong> — leaving <code>ondemand</code> on wastes the clock you paid for. Set <code>performance</code>.</li></ul><h2>Verification</h2><p>Once the server is on the CPU, prove the core is the bottleneck (or is not). Run <code>top</code>, press <code>1</code>, and watch the core the server is pinned to while it fills with players — if that one core approaches 100% <code>%us</code> while <a href="/tutorials/measure-server-fps">server FPS</a> sags, you have found your ceiling and only a faster core will raise it. If the core sits at 40% and FPS is still low, the CPU is not your problem — look at the <a href="/tutorials/fix-sys-ticrate-not-changing-fps"><code>sys_ticrate</code> setting</a> or the kernel timer instead. That is how you tell a hardware limit from a configuration one.</p> |
is-hlds-single-threaded/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Is HLDS Single-Threaded? What That Means for Your VPS" | |
| 3 | +excerpt: "Yes, one HLDS instance runs on a single core, why more cores never speed up one server, and how that reshapes how you size a VPS, pin instances, and read CPU graphs." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "cpu, architecture" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Short answer: <strong>yes</strong>. A single HLDS or <a href="/tutorials/hlds-vs-rehlds-explained">ReHLDS</a> instance runs its game simulation on one main thread, which lives on one CPU core. This one fact drives almost every hardware and hosting decision you make, and misunderstanding it is why admins buy the wrong VPS and then wonder why an 8-core box lags at 22 players. Here is what single-threaded actually means and how to plan around it.</p><h2>1. What "single-threaded" means in practice</h2><p>The engine's main loop — running player physics, entity logic, AMXX plugin forwards, and network snapshot building — executes sequentially on one thread. There are auxiliary threads for some I/O, but the work that determines your server fps and tick timing is on that single core. Consequently, a server's performance is bounded by <strong>single-core speed</strong>, not core count. A 32-slot server that pushes one core to 100% will not get faster if you add cores; the extra cores sit idle while the busy one saturates.</p><h2>2. Why more cores do not help one server</h2><p>Because the simulation cannot be split across cores, doubling your core count does nothing for a single instance's fps or its capacity to hold 1000 fps under load. What extra cores <em>do</em> give you is the ability to run <strong>more independent instances</strong> in parallel, each on its own core. Think of the CPU as a set of lanes: one server occupies one lane at a time, and a wider road only helps if you have more cars. This is the entire logic behind <a href="/tutorials/multiple-cs16-servers-one-vps">running multiple servers on one VPS</a>.</p><h2>3. Buy for single-core speed</h2><p>The corollary for hardware: when choosing a VPS or dedicated box for CS 1.6, prioritise high single-thread clock and IPC over core count. A 4-core CPU at 4.5 GHz per core will hold a smooth 32-slot server far better than a 16-core server chip at 2.2 GHz, even though the latter looks bigger on paper. The <a href="/tutorials/best-cpu-for-cs16-server">best CPU for a CS 1.6 server</a> guide ranks parts on exactly this metric; the headline is that GHz-per-core beats total cores for this workload.</p><h2>4. Pin instances to spread load</h2><p>If you run several servers on a multi-core box, the Linux scheduler may bounce instances between cores, causing fps jitter as caches thrash. Pin each instance to a dedicated core with <code>taskset</code>:</p><pre>taskset -c 0 ./hlds_run -game cstrike +port 27015 ... | |
| 10 | +taskset -c 1 ./hlds_run -game cstrike +port 27016 ...</pre><p>Now server one lives on core 0, server two on core 1, and neither steals the other's cache. The full method, including verifying the affinity, is in <a href="/tutorials/cpu-affinity-taskset-hlds">CPU affinity with taskset</a>.</p><h2>5. Read your CPU graphs correctly</h2><p>Because one instance is single-threaded, a system-wide CPU meter is misleading. On an 8-core box, one fully saturated HLDS instance shows as roughly <strong>12.5% total CPU</strong> — which looks idle — while that one core is actually pegged at 100% and the server is lagging. Always look at <em>per-core</em> utilisation. In <code>htop</code> press to show per-core bars, or in <code>top</code> press <code>1</code>:</p><pre>top -H -p $(pgrep -f 'hlds|hlds_linux')</pre><p><code>-H</code> shows threads, so you can see the busy main thread. If one core reads 100% while the aggregate looks low, you have found a single-threaded bottleneck, not spare capacity. Pair this with <a href="/tutorials/fix-hlds-100-cpu">fixing HLDS at 100% CPU</a>.</p><h2>Common errors</h2><ul><li><strong>Bought a many-core, low-clock server and it still lags</strong> — single-thread speed is what matters; cores do not help one instance.</li><li><strong>System CPU reads 15% but the server lags</strong> — you are reading aggregate, not per-core. One core is at 100%.</li><li><strong>Instances randomly stutter on a shared box</strong> — the scheduler is migrating them between cores. Pin with <code>taskset</code>.</li><li><strong>Expecting a plugin to "use another core"</strong> — AMXX plugins run on the main thread; a heavy plugin steals from the same single core the game uses.</li><li><strong>Adding cores to fix fps</strong> — will not work for one server; either raise clock speed or reduce the per-tick workload.</li></ul><h2>Verification</h2><p>Load your server to a realistic population and watch per-core usage:</p><pre>top -H -p $(pgrep -f hlds)</pre><p>Confirm one core carries the instance and that it is the constraint. If that core hits 100% before you reach your slot target, no amount of extra cores fixes it — move to a faster single-core CPU (see <a href="/tutorials/best-cpu-for-cs16-server">best CPU</a>) or lighten the tick with fewer heavy plugins. If you have idle cores and multiple servers, distribute them with <a href="/tutorials/cpu-affinity-taskset-hlds">taskset affinity</a> so each gets a full lane.</p> | |
| 0 | 11 |
