Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent e202b6bd31
commit b29ada425eb025519506e9593bc04fe44b8f1e36
2 changed files
with 25 additions and 0 deletions
diagnose-packet-loss-vps/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "Diagnosing Packet Loss on a Game Server VPS (mtr)" | |
| 3 | +excerpt: "How to use mtr to find where packets are actually being dropped on a game server's path, read per-hop Loss% correctly, and tell real network loss from server-side choke." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "packet-loss, network" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Players say the server "lags" or "rubber-bands" and you need to know whether the problem is the network dropping packets or the server itself choking. These are completely different fixes, and confusing them wastes hours. <code>mtr</code> — a continuous traceroute that pings every hop repeatedly — is the right tool for the network half. The trick is reading it correctly, because <code>mtr</code> lies to you about intermediate hops unless you know how it works.</p><h2>1. Install and run mtr</h2><pre>apt install mtr-tiny # Debian/Ubuntu | |
| 10 | +mtr --report --report-cycles 100 YOUR.SERVER.IP</pre><p><code>--report</code> runs a fixed number of cycles and prints a table instead of the live view; <code>--report-cycles 100</code> gives 100 samples per hop, enough to see real loss. Run it <strong>from a client toward the server</strong> and, separately, <strong>from the server toward a known-good target</strong> — loss can be one-directional, and testing both ways tells you which.</p><h2>2. Read the report</h2><p>A typical line looks like:</p><pre>HOST: client Loss% Snt Last Avg Best Wrst StDev | |
| 11 | + 1. 192.168.1.1 0.0% 100 0.4 0.5 0.3 1.1 0.1 | |
| 12 | + 5. core-router.isp.net 12.0% 100 14.2 15.0 13.8 40.1 3.2 | |
| 13 | + 9. YOUR.SERVER.IP 0.0% 100 38.5 39.1 37.9 55.2 2.1</pre><p>The columns that matter: <strong><code>Loss%</code></strong> (drops at that hop), <strong><code>Avg</code></strong> (mean latency), and <strong><code>Wrst</code>/<code>StDev</code></strong> (jitter). The final line is your server — that is the number that actually affects gameplay.</p><h2>3. The golden rule: only the last hop's loss counts</h2><p>The example above shows 12% loss at hop 5 but <strong>0% at the final hop</strong>. That intermediate loss is almost always a lie: routers deprioritize or rate-limit the ICMP replies <code>mtr</code> depends on, so they <em>report</em> loss while still forwarding your actual game traffic perfectly. The rule:</p><blockquote>Loss that appears at an intermediate hop but clears at every hop after it — including the destination — is ICMP rate-limiting, not real loss. Ignore it.</blockquote><p>Real, gameplay-affecting loss shows up at the <strong>final hop and persists</strong>. If the last line reads <code>0.0%</code>, the path is clean no matter how alarming the middle looks. If the last line reads <code>8.0%</code> and every hop after a certain point also shows loss, that is genuine and you have found roughly where it starts.</p><h2>4. Test UDP on the game port</h2><p>CS 1.6 is UDP, and some paths treat ICMP and UDP differently. Point <code>mtr</code> at the actual game port to test a path closer to what the game uses:</p><pre>mtr --udp --port 27015 --report --report-cycles 100 YOUR.SERVER.IP</pre><p>If ICMP mtr is clean but the UDP test to <code>27015</code> shows persistent loss at the destination, suspect something port-specific — a firewall, a <a href="/tutorials/ddos-protected-hosting">DDoS-scrubbing</a> filter mishandling game traffic, or the <a href="/tutorials/cs16-server-firewall-ports">firewall on the box</a>.</p><h2>5. Rule out server-side choke first</h2><p>Before blaming the network at all, check whether the "loss" is actually the server choking — they look identical to a player but are unrelated. In-game, read the scoreboard's <code>choke</code> and <code>loss</code> fields:</p><ul><li><strong>High <code>choke</code>, low network loss</strong> — the server is hitting a rate cap and cannot send fast enough. Fix <a href="/tutorials/sv-maxrate-maxupdaterate-values"><code>sv_maxrate</code>/<code>sv_maxupdaterate</code></a>, not the network. See <a href="/tutorials/fix-choke-loss-scoreboard">choke and loss explained</a>.</li><li><strong>Loss with a clean scoreboard-choke and a clean <code>mtr</code></strong> — look at the box: <code>ip -s link show eth0</code> for NIC <code>dropped</code>/<code>errors</code>, and <code>ss -u -a</code> for socket buffer overruns.</li></ul><h2>Common mistakes</h2><ul><li><strong>Panicking over mid-path loss</strong> — intermediate-hop <code>Loss%</code> that clears at the destination is ICMP rate-limiting, not real loss. Read the last hop.</li><li><strong>Testing only one direction</strong> — loss can be asymmetric. Run <code>mtr</code> both from the client to the server and from the server outward.</li><li><strong>Confusing choke with network loss</strong> — scoreboard <code>choke</code> is the server's rate cap; only <code>mtr</code> loss at the destination is the network.</li><li><strong>Too few cycles</strong> — a 5-sample run is noise. Use <code>--report-cycles 100</code> for a verdict.</li></ul><h2>Verification</h2><p>You have diagnosed it correctly when the numbers agree. Run a 100-cycle <code>mtr</code> to the server and confirm the <strong>final hop</strong> reads near <code>0.0%</code> loss with steady <code>Avg</code> and low <code>StDev</code>; intermediate loss you can now ignore with confidence. Cross-check the in-game scoreboard: if network loss is clean but players still see <code>loss</code> or <code>choke</code>, the problem is on the server, not the path, and you take it to <a href="/tutorials/fix-choke-loss-scoreboard">the choke/loss guide</a>. When both the destination hop and the scoreboard are clean and the complaints stop, the path is genuinely healthy — and if lag persists despite that, it is CPU or <a href="/tutorials/cpu-steal-time-vps">steal</a>, not the network.</p> |
profile-plugin-performance/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "Profiling Plugin Performance (Which Plugin Eats Your CPU)" | |
| 3 | +excerpt: "AMX Mod X has no built-in per-plugin profiler by default, so here is the honest toolkit: bisection with amxx pause, reading meta list and stats, and isolating the plugin that is dragging your fps down." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "plugins, profiling" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Your server fps sags under load and you suspect a plugin, but which one? The honest starting point: stock AMX Mod X does <strong>not</strong> ship an always-on per-plugin CPU profiler that hands you a milliseconds-per-plugin table. So the reliable technique is empirical — bisection — supported by the visibility tools the engine and AMXX do give you. This is the method experienced admins actually use to find the plugin eating a core.</p><h2>1. Establish a clean fps baseline</h2><p>You cannot spot a regression without a baseline. Under a realistic load (bots or a real population), read the server fps repeatedly:</p><pre>stats</pre><p>Note the steady <code>fps</code> figure with your full plugin set loaded. This is the number bisection will move. If you do not have a stable way to read it, set up <a href="/tutorials/measure-server-fps">fps measurement</a> first — a moving target makes bisection meaningless.</p><h2>2. Bisect with amxx pause</h2><p>The core technique: disable half your plugins, watch fps, and follow the half that changes it. <code>amxx pause</code> stops a plugin executing its forwards immediately for the current map, without editing files:</p><pre>amxx plugins | |
| 10 | +amxx pause someplugin.amxx</pre><p>Pause roughly half your loaded plugins, re-read <code>stats</code>, and see whether fps recovers. If it does, the culprit is in the paused half; unpause them and pause the other half to confirm. Then bisect within the guilty half — pause a quarter, then an eighth — until one plugin, when paused, restores your fps. That plugin is your CPU hog. This is the same divide-and-conquer used to find a crashing plugin in <a href="/tutorials/find-crashing-plugin">the crashing-plugin guide</a>, applied to fps instead of crashes.</p><h2>3. Read what is loaded and running</h2><p>Two listings tell you the state of everything so you bisect deliberately, not blindly:</p><pre>amxx plugins | |
| 11 | +meta list</pre><p><code>amxx plugins</code> shows each AMXX plugin as <code>running</code>, <code>paused</code> or <code>bad load</code>. <code>meta list</code> shows the Metamod modules (the heavier native code beneath AMXX) — a badly behaving Metamod plugin sits below AMXX and will not show as an <code>.amxx</code>, so if pausing every AMXX plugin does not help, the cost is in a Metamod module or the mod DLL itself.</p><h2>4. Reason about what makes a plugin expensive</h2><p>Bisection finds the plugin; understanding <em>why</em> lets you fix it. The expensive plugins are almost always the ones doing work <strong>every frame or every player, every tick</strong>: a plugin hooking <code>client_PreThink</code> / <code>FM_PlayerPreThink</code> and looping all players, running per-frame glow or knockback math, or doing string work in a high-frequency forward. A plugin that only fires on <code>DeathMsg</code> costs almost nothing; one that runs on every server frame costs 32× more on a full 32-slot server than an empty one, which is why the problem only appears under load. Match the plugin you found to how often its forwards fire.</p><h2>5. Confirm the fix, do not guess</h2><p>Once you have a suspect, prove it: pause it on a full server, confirm fps recovers and stays recovered for several minutes, then unpause and confirm fps drops again. That before/after is the proof — a one-off <code>stats</code> reading is too noisy. If the plugin is essential, look for a lighter replacement or a configuration that reduces its per-frame work (raise its task interval, disable its effects) rather than running it as-is. Some AMXX builds expose additional debug/JIT diagnostics, but the pause-and-measure loop above needs no special build and is what most admins rely on.</p><h2>Common errors</h2><ul><li><strong>Pausing every plugin barely changes fps</strong> — the cost is not in an AMXX plugin. Look at Metamod modules (<code>meta list</code>), the mod DLL, or a genuine CPU/engine bottleneck.</li><li><strong>fps recovers after pause but the plugin is essential</strong> — it is doing heavy per-frame work. Reduce its frequency or replace it, do not just live with it.</li><li><strong>Bisection results are inconsistent</strong> — the load is not steady (players joining/leaving). Use a fixed bot count so the baseline holds.</li><li><strong>Paused plugin comes back next map</strong> — <code>amxx pause</code> only lasts the current map; comment its line in <code>plugins.ini</code> to disable it durably.</li><li><strong>Expecting a built-in profiler table</strong> — stock AMXX does not provide one; bisection is the honest method.</li></ul><h2>Verification</h2><p>After identifying and disabling or fixing the culprit, load the server to full population again and confirm the fps baseline is restored and stable:</p><pre>stats | |
| 12 | +amxx plugins</pre><p>The <code>fps</code> figure under full load should now sit at or near your target, and the guilty plugin should be paused, removed, or reconfigured. Re-run the bisection occasionally after adding new plugins — the cheapest time to catch a CPU-hungry plugin is right after you install it, not after players complain. For fps problems that survive removing every plugin, the issue is engine or hardware; work through <a href="/tutorials/fix-hlds-100-cpu">HLDS at 100% CPU</a> and <a href="/tutorials/fix-low-server-fps-linux">low server fps on Linux</a>.</p> | |
| 0 | 13 |
