Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent 408512846f
commit b6a3aea7cb22f7974554cec332d2b722e9dc04bc
2 changed files
with 22 additions and 0 deletions
datacenter-location-ping/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Choosing a Datacenter Location for the Lowest Player Ping" | |
| 3 | +excerpt: "How to pick a hosting region for the lowest ping to your actual player base, why peering matters more than raw distance, and how to test routes before you pay." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "hosting, ping" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The single biggest lever on how a CS 1.6 server <em>feels</em> is not the CPU or the cvars — it is physical and network distance between the server and its players. Ping is dominated by the speed of light over the path plus every router hop in between, and no amount of <a href="/tutorials/sv-maxrate-maxupdaterate-values">rate tuning</a> reduces it. So the location decision, made before you rent anything, sets the floor for everyone's experience. Here is how to choose it deliberately and test it before paying.</p><h2>1. Locate your players, not the map</h2><p>Host near where your players actually connect from, not near you and not near some notional "center." If your community is Eastern European, a datacenter in Warsaw or Bucharest serves them far better than one in the US, even if the US box is cheaper or you personally live there. Before choosing, get a rough geography of your player base — from your community, your server stats, or a geoip breakdown of connecting IPs — and pick the region that minimizes ping for the <em>majority</em>, accepting that outliers will always have higher ping.</p><h2>2. Distance sets the floor, peering sets the reality</h2><p>Raw distance gives a hard physical minimum — light in fibre travels roughly 200,000 km/s, so about 1 ms per 100 km each way, before any routers. But the <em>actual</em> ping is usually worse than the straight-line minimum because of how networks interconnect. Two datacenters equidistant from your players can differ by 20–40 ms because one has good local <strong>peering</strong> (direct exchange with the ISPs your players use) and the other routes traffic out to a distant exchange and back. A well-peered host 500 km away can beat a badly-connected one 200 km away. Distance is necessary; peering is what separates good hosts from bad at the same distance.</p><h2>3. Test the route before you buy</h2><p>Never take a host's word for latency — measure it. Most reputable hosts publish a <strong>looking glass</strong> (a web tool) and a <strong>test IP / test file</strong> for each datacenter. Use them from a machine on the network your players use:</p><pre>ping -c 20 TEST.IP.OF.DATACENTER | |
| 10 | +mtr --report --report-cycles 50 TEST.IP.OF.DATACENTER</pre><p>Read the <code>ping</code> average and the per-hop <code>Avg</code>/<code>Loss%</code> from <a href="/tutorials/diagnose-packet-loss-vps"><code>mtr</code></a>. Better still, have a couple of real players in your target region run the same test to the host's looking glass — their numbers are the ones that count, not yours. A host without a public test IP or looking glass is a host asking you to buy latency blind.</p><h2>4. Compare candidates on the same players</h2><p>Shortlist two or three datacenters and test them all from the same set of player locations. Line up the results:</p><ul><li><strong>Median ping</strong> across your test points — the headline.</li><li><strong>Worst-case ping</strong> for the region you care about — who gets left behind.</li><li><strong>Loss and jitter</strong> — a stable 40 ms beats a jittery 30 ms that spikes; jitter ruins hit registration more than a slightly higher steady ping.</li></ul><p>Pick the one that is best for the bulk of your players on median <em>and</em> holds steady, not the one with the single lowest number to your own PC.</p><h2>5. Don't trade away everything else</h2><p>Location is the biggest lever but not the only one. A perfectly-placed datacenter on an oversold node still lags from <a href="/tutorials/cpu-steal-time-vps">steal</a>, and a low-ping host with no <a href="/tutorials/ddos-protected-hosting">DDoS protection</a> goes down the first time someone attacks it. Weigh ping alongside CPU quality and protection — see <a href="/tutorials/choose-vps-for-cs16">choosing a VPS for CS 1.6</a> for the full checklist. The goal is the lowest ping <em>among hosts that are otherwise good enough</em>, not the lowest ping at any cost.</p><h2>Common mistakes</h2><ul><li><strong>Hosting near yourself</strong> — your ping is irrelevant if your players are elsewhere. Host near the majority.</li><li><strong>Choosing on distance alone</strong> — peering can swing real ping by tens of ms at equal distance. Test the route.</li><li><strong>Testing only from your own PC</strong> — use the host's looking glass and real players in the target region.</li><li><strong>Ignoring jitter</strong> — a steady 40 ms plays better than a spiky 30 ms. Read loss and variance, not just the average.</li></ul><h2>Verification</h2><p>After you deploy, confirm the real experience matches the pre-purchase test. Have players in your main region connect and read their in-game ping on the scoreboard — it should land near the <code>mtr</code>/looking-glass numbers you measured, within a few ms. If in-game ping is much higher than your route test suggested, the extra latency is being added on the server side, not the network — check for <a href="/tutorials/fix-high-ping-only-my-server">server-induced ping</a> from an overloaded core or bad rates. If it matches, you chose the location correctly and everyone in your target region is playing at the physical floor for that path.</p> |
optimize-zombie-server/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "Optimizing a Zombie Server (Precache, Entities, Rates)" | |
| 3 | +excerpt: "Why zombie mods are the heaviest CS 1.6 workload, how to tame precache from custom models and sounds, keep the edict count under control, and tune rates so knockback and infection feel crisp." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "zombie-plague, performance" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Zombie servers are the most resource-hungry thing you can run on the GoldSrc engine. A single Zombie Plague-style mod piles on custom zombie/human models, dozens of custom sounds, ammo-pack entities, particle and effect entities, and heavy per-frame knockback math — all on <a href="/tutorials/is-hlds-single-threaded">one core</a>. Left untuned it hits precache ceilings, exhausts edicts, and feels mushy. Here is how to make a zombie server both stable and crisp.</p><h2>1. Tame the precache load</h2><p>Zombie mods precache far more than vanilla CS: multiple zombie models, human models, weapon models, and a wall of custom WAVs for infection, groans and ambience. Each is a slot against the engine's model and sound ceilings, and overrunning them crashes the map on load. Audit what the mod actually uses versus what it precaches "just in case", and cut custom classes you do not run. Share models between classes where possible instead of shipping a unique model per class. The exact ceilings and the overflow errors are in <a href="/tutorials/precache-limits-performance">precache limits</a>, <a href="/tutorials/fix-model-overflow-precache">model overflow</a>, and <a href="/tutorials/fix-sound-slots-overflow">sound slot overflow</a>.</p><h2>2. Watch the edict count</h2><p>Ammo packs, dropped weapons, grenades, and every visual effect a zombie mod spawns are entities, and a busy 32-player zombie round can approach the engine's edict ceiling. When it does you get:</p><pre>Host_Error: PF_precache_model_I: Model ... failed to precache | |
| 10 | +ED_Alloc: no free edicts</pre><p>Reduce the number of simultaneous effect entities the mod spawns, cap decorative particles, and clean up dropped items faster. The failure mode and the cvars that raise or manage the ceiling are covered in <a href="/tutorials/fix-max-edicts-too-many-entities">too many entities / max edicts</a>.</p><h2>3. Tune rates for knockback feel</h2><p>Zombie gameplay lives and dies by knockback, and knockback is applied server-side and delivered through the same update stream as everything else. If clients are choking, the knockback push arrives late and infection feels laggy and unfair. Run the full high-update config so the fast, physical zombie combat stays responsive:</p><pre>sv_maxupdaterate 100 | |
| 11 | +sv_maxrate 25000 | |
| 12 | +sv_minrate 5000</pre><p>and eliminate choke as described in <a href="/tutorials/eliminate-choke-server">the choke guide</a>. Because a zombie server is often full and fast, a stable high server fps matters even more than on a standard server — verify it under load with <code>stats</code> and the <a href="/tutorials/stable-1000-fps-linux-server">stable 1000 fps</a> guide.</p><h2>4. Keep per-frame plugin cost down</h2><p>Knockback, glow, and ambience plugins often run every frame for every player, and on a full zombie server that is the dominant CPU cost. Run a lean, well-written core rather than stacking add-ons. Our own <a href="/plugins/csb-zombie-core">CSB Zombie Core</a> and <a href="/plugins/csb-zombie-classes">CSB Zombie Classes</a> are built to keep the per-frame work bounded; if you run a different base, profile it (disable half the add-ons, watch fps) using <a href="/tutorials/profile-plugin-performance">plugin profiling</a> to find which effect plugin is eating the core.</p><h2>5. Right-size the server</h2><p>Given the load, a zombie server needs a fast single core and enough RAM for the fat precache. Force the <a href="/tutorials/cpu-governor-performance">performance governor</a>, run <a href="/tutorials/hlds-vs-rehlds-explained">ReHLDS</a> for the extra efficiency, and if you host other servers on the box, give the zombie instance its own pinned core with <a href="/tutorials/cpu-affinity-taskset-hlds">taskset</a> because it will starve neighbours otherwise. New to the mod itself? Start from <a href="/tutorials/install-zombie-plague-mod">installing Zombie Plague</a> and optimise from there.</p><h2>Common errors</h2><ul><li><strong>Map crashes on load with a precache error</strong> — too many custom models or sounds. Cut classes and share models; see the precache guides.</li><li><strong>"no free edicts" mid-round</strong> — effect and item entities exhausted the edict pool. Reduce simultaneous effects and clean up items.</li><li><strong>Infection/knockback feels laggy</strong> — clients are choking or server fps sags when full. Fix rates and fps under load.</li><li><strong>fps collapses only on a full zombie round</strong> — a per-frame effect plugin scaling with player count. Profile and trim it.</li><li><strong>Zombie server drags down other servers on the box</strong> — it is not pinned; it is stealing a shared core. Give it a dedicated core.</li></ul><h2>Verification</h2><p>Fill the server (bots to your max), run a full infection round, and watch the ceilings and fps together:</p><pre>stats</pre><p>Confirm the map loads without precache errors, no <code>ED_Alloc</code> messages appear during a busy round, <code>fps</code> stays high with the server full, and a connected client shows zero choke on <a href="/tutorials/cs16-net-graph-guide">net_graph 3</a> even as knockback flies. If all four hold on a full round, the server is optimised; if precache or edicts fail, cut custom content before touching anything else, because no rate or fps tuning can save a server that crashes on map load.</p> | |
| 0 | 13 |
