Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent aea08afc89
commit 23c668c847622486ff6d2df9dcf140b41e865be5
2 changed files
with 134 additions and 0 deletions
fix-choke-loss-scoreboard/en.md
A
| @@ -0,0 +1,70 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Players Show Choke and Loss on the Scoreboard" | |
| 3 | +excerpt: "Choke and loss look similar but have opposite causes: choke is your server hitting a rate cap, loss is real packet loss. How to tell them apart with net_graph and fix each." | |
| 4 | +category: "errors" | |
| 5 | +tags: "choke, rates" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p><em>Choke</em> and <em>loss</em> both make the game feel rubbery, but they are opposite problems. Choke means the server wants to send more updates than the configured rate allows, so it holds packets back — a configuration problem you own. Loss means packets are genuinely disappearing on the wire — a network problem. Fixing them requires telling them apart first, and <code>net_graph</code> does exactly that.</p> | |
| 10 | + | |
| 11 | +<h2>1. Read net_graph to identify which one</h2> | |
| 12 | +<p>Have an affected player enable the graph:</p> | |
| 13 | +<pre>net_graph 3 | |
| 14 | +net_graphpos 2</pre> | |
| 15 | +<p>The graph shows separate <code>choke</code> and <code>loss</code> counters. Non-zero <strong>choke</strong> with zero loss is a rate-cap problem. Non-zero <strong>loss</strong> is packets dropped in transit. They can occur together, but treat them separately.</p> | |
| 16 | + | |
| 17 | +<h2>2. Fix choke: raise the server rate caps</h2> | |
| 18 | +<p>Choke appears when a client's requested update rate exceeds what the server will deliver, or when <code>sv_maxrate</code> is too low for the data volume. In <code>server.cfg</code>:</p> | |
| 19 | +<pre>sv_maxrate 25000 | |
| 20 | +sv_minrate 15000 | |
| 21 | +sv_maxupdaterate 101 | |
| 22 | +sv_minupdaterate 30</pre> | |
| 23 | +<p>The old <code>sv_maxrate 9999</code> / <code>sv_maxupdaterate 30</code> defaults choke instantly on a full, busy server. 25000 bytes/s and 101 updates are sane modern values.</p> | |
| 24 | + | |
| 25 | +<h2>3. The FPS-vs-updaterate rule</h2> | |
| 26 | +<p>A server cannot send more updates per second than it runs frames per second. If <code>sv_maxupdaterate</code> is 100 but the server runs at 64 FPS, everyone chokes down to ~64 no matter what. Confirm FPS with <code>stats</code> in the console and, on Linux, raise it:</p> | |
| 27 | +<pre>sys_ticrate 1000 | |
| 28 | +fps_max 1000</pre> | |
| 29 | +<p>Rule of thumb: server FPS should be at least equal to <code>sv_maxupdaterate</code>. See the <a href="/tutorials/fix-high-ping-only-my-server">high-ping guide</a> — low FPS causes both choke and ping.</p> | |
| 30 | + | |
| 31 | +<h2>4. Set sane client rates</h2> | |
| 32 | +<p>Client cvars must fit inside the server caps. A good client baseline:</p> | |
| 33 | +<pre>rate 25000 | |
| 34 | +cl_updaterate 101 | |
| 35 | +cl_cmdrate 101</pre> | |
| 36 | +<p>If a client sets <code>cl_updaterate 128</code> against a server capped at 101, the server clamps it and the extra shows as choke on that player only. You can standardise this server-side with <code>sv_maxupdaterate</code> so no client can exceed it.</p> | |
| 37 | + | |
| 38 | +<h2>5. Fix loss: it is the network</h2> | |
| 39 | +<p>Loss is not fixable with cvars. Have the player run a route trace to find where packets die:</p> | |
| 40 | +<pre>mtr YOUR_SERVER_IP # Linux | |
| 41 | +pathping YOUR_SERVER_IP # Windows</pre> | |
| 42 | +<p>Loss that starts at a specific hop and continues to the end is a real drop point — the player's ISP, a transit provider, or your host. Loss only on the final hop is usually the server host or a saturated uplink; open a ticket with the trace. Also check the server is not itself dropping packets from an overloaded NIC or an <code>iptables</code> rate limit you forgot about.</p> | |
| 43 | + | |
| 44 | +<h2>6. MTU and fragmentation</h2> | |
| 45 | +<p>Consistent low-level loss for players on certain connections (PPPoE, some mobile links) can be MTU fragmentation. This is edge-case, but if a subset of players always show 1–2% loss while LAN players show none, MTU is a suspect. It is a client-side / ISP concern; there is no server cvar that fixes a fragmented path.</p> | |
| 46 | + | |
| 47 | +<h2>7. A reference rate configuration</h2> | |
| 48 | +<p>For a modern public server, these are the server and client values that eliminate choke for the vast majority of connections. Server side, in <code>server.cfg</code>:</p> | |
| 49 | +<table> | |
| 50 | +<thead><tr><th>Cvar</th><th>Value</th><th>Purpose</th></tr></thead> | |
| 51 | +<tbody> | |
| 52 | +<tr><td><code>sv_maxrate</code></td><td>25000</td><td>Max bytes/s per client</td></tr> | |
| 53 | +<tr><td><code>sv_minrate</code></td><td>15000</td><td>Floor so nobody starves themselves</td></tr> | |
| 54 | +<tr><td><code>sv_maxupdaterate</code></td><td>101</td><td>Cap on updates/s the server sends</td></tr> | |
| 55 | +<tr><td><code>sv_minupdaterate</code></td><td>30</td><td>Floor for playable prediction</td></tr> | |
| 56 | +<tr><td><code>fps_max</code> / <code>sys_ticrate</code></td><td>1000</td><td>Server FPS ceiling (Linux)</td></tr> | |
| 57 | +</tbody> | |
| 58 | +</table> | |
| 59 | +<p>Client side, a player suggests: <code>rate 25000</code>, <code>cl_updaterate 101</code>, <code>cl_cmdrate 101</code>. Because the server clamps to its own caps, no client can force values that would choke the whole server — the caps are the real control.</p> | |
| 60 | + | |
| 61 | +<h2>Common errors</h2> | |
| 62 | +<ul> | |
| 63 | +<li><strong>Whole server chokes at once</strong> — <code>sv_maxrate</code> too low or server FPS below <code>sv_maxupdaterate</code>. Fix caps and FPS.</li> | |
| 64 | +<li><strong>One player chokes, rest fine</strong> — that client requested a rate above the server cap; harmless, or lower their <code>cl_updaterate</code>.</li> | |
| 65 | +<li><strong>Loss but zero choke</strong> — packet loss on the path. cvars will not help; trace the route.</li> | |
| 66 | +<li><strong>Choke spikes only on smoke/flash-heavy rounds</strong> — data burst exceeding <code>sv_maxrate</code>. Raise it to 25000.</li> | |
| 67 | +</ul> | |
| 68 | + | |
| 69 | +<h2>Verification</h2> | |
| 70 | +<p>After raising the caps and confirming FPS, have the same player watch <code>net_graph 3</code> through a full round. Choke should sit at 0 during normal play and only tick up briefly during heavy grenade spam. If loss is still non-zero, the problem was never choke — it is the network, and the route trace is your evidence for the host ticket.</p> |
fix-connection-failed-4-retries/en.md
A
| @@ -0,0 +1,64 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Connection failed after 4 retries' on Your Server" | |
| 3 | +excerpt: "The connect handshake behind 'Connection failed after 4 retries' - UDP reachability, sv_lan, rate/netchan limits, wrong port, and provider-level UDP filtering - each with a concrete test." | |
| 4 | +category: "errors" | |
| 5 | +tags: "connection, networking" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p><code>Connection failed after 4 retries</code> means the client sent its connection request four times and never got a usable reply. The game found the server in a list (or you typed <code>connect</code>), but the UDP handshake did not complete. This is a reachability or handshake problem, essentially never a "the map is wrong" problem. The whole job is to find where the packets are being dropped.</p> | |
| 10 | + | |
| 11 | +<h2>1. Prove the server is actually listening</h2> | |
| 12 | +<p>On the server host:</p> | |
| 13 | +<pre>ss -lunp | grep 27015</pre> | |
| 14 | +<p>You must see <code>hlds_linux</code> (or <code>hlds.exe</code>) bound to UDP 27015. If it is bound to <code>127.0.0.1</code> only, remote clients can never reach it — start with an explicit bind address:</p> | |
| 15 | +<pre>./hlds_run -game cstrike -ip 0.0.0.0 -port 27015 +maxplayers 20 +map de_dust2</pre> | |
| 16 | +<p>If nothing is listening, the server is not running and the retries are expected; fix the server start first.</p> | |
| 17 | + | |
| 18 | +<h2>2. Test UDP reachability from outside</h2> | |
| 19 | +<p>Ping and TCP tools lie here because CS 1.6 is UDP. Query the port from another machine. A raw check with netcat confirms the port is at least reachable:</p> | |
| 20 | +<pre>nc -u -v -w3 YOUR_SERVER_IP 27015</pre> | |
| 21 | +<p>The cleanest external test is to open the server browser on a friend's connection and query by IP. If the server answers a query but the <em>connect</em> still fails after 4 retries, the problem is in the handshake (rate/netchan), not raw reachability — jump to step 5.</p> | |
| 22 | + | |
| 23 | +<h2>3. Firewall on the host</h2> | |
| 24 | +<p>The rule people forget is that both directions of UDP 27015 must pass. On Linux with ufw:</p> | |
| 25 | +<pre>sudo ufw allow 27015/udp | |
| 26 | +sudo ufw status</pre> | |
| 27 | +<p>Also check the provider's firewall/security group — many VPS panels have a separate network-level firewall that ufw cannot see. And check <code>iptables -L -n</code> for a stray DROP rule if you did not set up ufw yourself.</p> | |
| 28 | + | |
| 29 | +<h2>4. Wrong port or sv_lan</h2> | |
| 30 | +<p>If you moved the server off 27015 with <code>-port</code>, clients must use <code>connect IP:PORT</code> with the real port. And on the server, <code>sv_lan 1</code> makes the engine treat the world as a LAN: it will reject or fail public clients. For an internet server it must be:</p> | |
| 31 | +<pre>sv_lan 0</pre> | |
| 32 | +<p>See <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the base install guide</a> for the full launch-line context.</p> | |
| 33 | + | |
| 34 | +<h2>5. Rate and netchannel limits rejecting the handshake</h2> | |
| 35 | +<p>If the query works but connect fails, the client's requested rate can fall outside the server's allowed band and the connection is dropped mid-handshake. Sane values in <code>server.cfg</code>:</p> | |
| 36 | +<pre>sv_minrate 5000 | |
| 37 | +sv_maxrate 25000 | |
| 38 | +sv_minupdaterate 30 | |
| 39 | +sv_maxupdaterate 101 | |
| 40 | +sv_max_queries_sec 3 | |
| 41 | +sv_max_queries_window 30</pre> | |
| 42 | +<p>Overly aggressive query-throttle cvars (<code>sv_max_queries_sec</code> set very low) can also drop the initial packet under load. On ReHLDS, an over-strict <code>sv_rehlds_force_dlmax</code> plus a client that cannot negotiate the download size can also stall the join — turn security cvars on one at a time and retest.</p> | |
| 43 | + | |
| 44 | +<h2>6. The 25th Anniversary / steam_legacy split</h2> | |
| 45 | +<p>Since the 2023 25th Anniversary update, protocol changes between the modern client and old server builds cause connect failures that look exactly like this. If only some players fail, ask whether they are on the modern client or the <code>steam_legacy</code> branch, and make sure your engine is a current <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> build that speaks the current protocol.</p> | |
| 46 | + | |
| 47 | +<h2>7. Watch the handshake from the server side</h2> | |
| 48 | +<p>The server console tells you how far each attempt gets. Leave it open while a test client tries to connect:</p> | |
| 49 | +<pre>status | |
| 50 | +developer 1</pre> | |
| 51 | +<p>If you see the client appear and then vanish (a <code>connect</code> line followed by a drop), the packets are arriving and the handshake itself is failing — that is the rate/netchan or protocol case, not a firewall. If <em>nothing at all</em> shows up on the server when the client tries, the request never reached you: firewall, wrong IP/port, or provider-level UDP filtering. That single observation splits the entire problem in half. Turn <code>developer</code> back to 0 afterwards — it is noisy.</p> | |
| 52 | + | |
| 53 | +<h2>Common errors</h2> | |
| 54 | +<ul> | |
| 55 | +<li><strong>Query works, connect fails</strong> — rate/netchan mismatch or a query-throttle cvar dropping packets. Widen the rate band.</li> | |
| 56 | +<li><strong>Nothing responds at all</strong> — firewall (host or provider), server bound to localhost, or wrong port.</li> | |
| 57 | +<li><strong>Only some players fail</strong> — client protocol split (modern vs <code>steam_legacy</code>), or their own ISP blocking UDP.</li> | |
| 58 | +<li><strong>Works on LAN, fails on the internet</strong> — <code>sv_lan 1</code>, or the public UDP port is not forwarded/allowed.</li> | |
| 59 | +</ul> | |
| 60 | + | |
| 61 | +<h2>Verification</h2> | |
| 62 | +<p>From a machine on a different network, run:</p> | |
| 63 | +<pre>connect YOUR_SERVER_IP:27015</pre> | |
| 64 | +<p>A successful join that spawns you into the map is the only real proof. If the server still cannot be reached at all after opening the firewall, it may also be missing from the master list for the same UDP reason — cross-check with the same reachability tests, and confirm <code>sv_lan 0</code> is set and the server can heartbeat outbound.</p> | |
| 0 | 65 |
