Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent 8357693932
commit a010b65645e06743cbf13d30c6b30382a047e7d2
2 changed files
with 32 additions and 0 deletions
bandwidth-math-cs16/en.md
A
| @@ -0,0 +1,15 @@ | ||
| 1 | +--- | |
| 2 | +title: "Bandwidth Math: How Much Traffic Does a 32-Slot Server Use?" | |
| 3 | +excerpt: "A worked estimate of the outbound and inbound bandwidth a full CS 1.6 server consumes, how rates and updaterate drive it, and how to turn Mbps into a monthly total." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "bandwidth, planning" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>"Will my line handle a 32-slot server?" is answerable with arithmetic, not guesswork. CS 1.6 traffic is dominated by the stream of snapshot packets the server sends each client, and that stream is governed by two things you control: how many updates per second each client gets (<code>cl_updaterate</code>, capped by <code>sv_maxupdaterate</code>) and how big each update is allowed to be (<code>rate</code>, capped by <a href="/tutorials/sv-maxrate-maxupdaterate-values"><code>sv_maxrate</code></a>). Here is the calculation, with realistic numbers and the caveats that make it an estimate rather than a promise.</p><h2>1. The per-client formula</h2><p>Outbound traffic to one client is, roughly:</p><pre>bytes_per_second = snapshot_size_bytes * updates_per_second</pre><p>The engine will never exceed the client's <code>rate</code> (bytes/second), so <code>rate</code> is a hard ceiling on that product. In practice a snapshot on a busy public server is on the order of <strong>100–200 bytes</strong> after delta-compression, depending on how many players are visible and how much is moving.</p><h2>2. Worked example: one player</h2><p>Take a common competitive-ish setup — <code>cl_updaterate 100</code>, a snapshot around 150 bytes:</p><pre>150 bytes * 100 /s = 15,000 bytes/s = ~15 KB/s down per player | |
| 10 | +15 KB/s * 8 = 120 kbps per player</pre><p>Note this sits comfortably under a <code>rate 25000</code> ceiling, so <code>rate</code> is not the limiter here; the update rate and snapshot size are. Drop the client to <code>cl_updaterate 60</code> and the same math gives ~9 KB/s. Push a chaotic mod where every snapshot is near the <code>rate</code> cap and you approach 25 KB/s.</p><h2>3. Scale to 32 slots</h2><p>Multiply by the player count for the outbound total the server pushes:</p><pre>32 players * 15 KB/s = 480 KB/s down | |
| 11 | +480 KB/s * 8 = ~3.8 Mbps outbound (server -> players)</pre><p>So a full 32-slot server at 100 updates/s lands around <strong>2.5–5 Mbps outbound</strong> depending on snapshot size. Inbound (client commands, governed by <code>cl_cmdrate</code>) is much smaller — client command packets are tiny — so figure inbound at roughly a quarter to a third of outbound, on the order of <strong>1–1.5 Mbps</strong>. The server's uplink is the number that matters, because that is the direction that saturates first.</p><h2>4. Mods change everything</h2><p>The 150-byte figure is for standard gameplay. Traffic scales with how much state is in flight:</p><ul><li><strong>Zombie / deathmatch / 100-player mods</strong> — more visible entities, more movement, bigger snapshots. Budget higher, and cap it with <code>sv_maxrate</code> or the uplink melts.</li><li><strong>Custom models and sprites</strong> — irrelevant to steady-state rate, but the initial download per join is large; that is a <a href="/tutorials/fastdl-download-speed-tuning">FastDL</a> concern, not a snapshot-rate one.</li><li><strong>Higher <code>sv_maxupdaterate</code></strong> — raising the cap lets clients pull more updates, multiplying the whole calculation.</li></ul><h2>5. Turn Mbps into a monthly total</h2><p>Hosts bill on transfer, so convert sustained rate to a month of full play. Take 4 Mbps outbound sustained:</p><pre>4 Mbps / 8 = 0.5 MB/s | |
| 12 | +0.5 MB/s * 3600 = 1.8 GB/hour | |
| 13 | +1.8 GB/hour * 24 * 30 = ~1.3 TB/month at 100% full, 24/7</pre><p>Real servers are not full 24/7, so halve or quarter that for a realistic average. Even the worst case — ~1.3 TB out plus inbound — is trivial for any host with an unmetered or multi-terabyte allowance, but it is exactly the kind of number that trips a cheap capped VPS. If you are sizing a line, size the <em>uplink</em> in Mbps first and the monthly cap second.</p><h2>Common mistakes</h2><ul><li><strong>Budgeting on <code>rate</code> alone</strong> — <code>rate</code> is a ceiling, not the actual usage. Actual usage is snapshot size times updaterate, usually well below the ceiling.</li><li><strong>Forgetting the server caps clients</strong> — a client asking for <code>cl_updaterate 1000</code> only gets what <code>sv_maxupdaterate</code> allows, so your math uses the server cap.</li><li><strong>Assuming symmetric traffic</strong> — outbound dwarfs inbound. Size the uplink, not the downlink.</li><li><strong>Ignoring the mod</strong> — a zombie server can double or triple these figures. Measure, do not assume.</li></ul><h2>Verification</h2><p>Do not trust the estimate — measure it. On the server box, watch the interface counters while the server fills:</p><pre>vnstat -l -i eth0 | |
| 14 | +# or, live per-second: | |
| 15 | +ifstat 1</pre><p>Watch the transmit column climb as players join; at 32 players it should sit in the low single-digit Mbps for standard play, higher for a heavy mod. Cross-check against your rate settings — if outbound is far above the formula, a client is choking or your snapshots are oversized; see <a href="/tutorials/fix-choke-loss-scoreboard">choke and loss on the scoreboard</a>. Once measured, size the host uplink with headroom (2–3x the peak) so a full server never saturates the pipe.</p> |
fastdl-download-speed-tuning/en.md
A
| @@ -0,0 +1,17 @@ | ||
| 1 | +--- | |
| 2 | +title: "Making FastDL Downloads Fast (Compression, CDN, Caching)" | |
| 3 | +excerpt: "Why FastDL is slow by default, how bzip2 pre-compression, a real web server, correct MIME types, and a Cloudflare CDN turn a minute-long map download into a few seconds." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "fastdl, performance" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A working <a href="/tutorials/fastdl-setup-guide">FastDL</a> mirror already beats the ancient in-game UDP transfer, but "working" and "fast" are different things. A player joining a map with 30 MB of custom content should wait seconds, not a minute. The speed comes from four levers: pre-compressing the files, serving them from a real web server tuned for static files, setting correct MIME types, and putting a CDN in front. Here is how to pull each one.</p><h2>1. Pre-compress every file with bzip2</h2><p>The client understands bzip2-compressed downloads natively: if it requests <code>maps/de_rats.bsp</code> and your mirror has <code>maps/de_rats.bsp.bz2</code>, it pulls the smaller compressed file and decompresses locally. A <code>.bsp</code> often shrinks 40–70%, so this is the biggest single win. Compress the whole tree once:</p><pre>find /var/www/fastdl/cstrike -type f \( -name '*.bsp' -o -name '*.mdl' -o -name '*.wav' -o -name '*.spr' -o -name '*.tga' \) -exec bzip2 -k9 {} \;</pre><p><code>-k</code> keeps the original (some clients still fetch the raw file), <code>-9</code> is maximum compression. Re-run it whenever you add maps. Full detail is in <a href="/tutorials/fastdl-bzip2-compression">the bzip2 compression guide</a>.</p><h2>2. Serve from nginx, not the game server</h2><p>Never point <code>sv_downloadurl</code> at the game box's own trickle transfer. Use nginx (or Apache) tuned for static delivery:</p><pre>location /cstrike/ { | |
| 10 | + root /var/www/fastdl; | |
| 11 | + sendfile on; | |
| 12 | + tcp_nopush on; | |
| 13 | + keepalive_timeout 30; | |
| 14 | + gzip off; | |
| 15 | +}</pre><p><code>sendfile on</code> lets the kernel copy the file straight to the socket without buffering through userspace; <code>tcp_nopush</code> batches headers with data; <code>keepalive</code> reuses the connection across the many small files a map references. Leave <code>gzip off</code> for the <code>.bz2</code> files — they are already compressed and re-compressing wastes CPU.</p><h2>3. Set the MIME type so browsers and the CDN cache it</h2><p>If the web server returns the wrong <code>Content-Type</code>, some clients and most CDNs refuse to cache the file. Add the bzip2 type:</p><pre>types { | |
| 16 | + application/x-bzip2 bz2; | |
| 17 | +}</pre><p>A missing MIME type is the classic reason a CDN passes every request through to origin instead of serving from cache — the download works but never gets faster.</p><h2>4. Put Cloudflare in front and cache aggressively</h2><p>Map and model files never change once published, so they are ideal CDN content. Point <code>sv_downloadurl</code> at a hostname proxied through <a href="/tutorials/fastdl-cloudflare-cdn">Cloudflare</a>, then set a Cache Rule that caches the <code>.bz2</code> extensions at the edge with a long TTL:</p><pre>Cache-Control: public, max-age=2592000, immutable</pre><p>The first player from a region pulls from your origin; everyone after pulls from the nearest Cloudflare edge at full line speed. This is what turns a globally slow mirror into a fast one regardless of where your VPS lives.</p><h2>5. Know the limits you cannot beat</h2><p>The client downloads FastDL files largely sequentially during the loading screen, so raw per-file latency matters more than total bandwidth — which is exactly why edge caching and keepalive help most. You cannot force parallel downloads from the engine side. The remaining lever is <em>content volume</em>: every custom model, sound and sprite a map references is a file to fetch, and the loading screen cannot finish until the last one arrives. Trimming unused custom content, sharing models between maps, and dropping oversized WAVs down to what the engine actually needs shortens the download more reliably than any server tweak — a 30 MB map that becomes an 18 MB map after removing three unused high-resolution skyboxes downloads faster for every single player, forever.</p><h2>Common errors</h2><ul><li><strong>Downloads work but stay slow</strong> — no <code>.bz2</code> files on the mirror, so clients pull the full-size originals. Run the compression pass.</li><li><strong>CDN never caches, every request hits origin</strong> — missing or wrong MIME type, or no cache rule for <code>.bz2</code>. Fix the <code>types</code> block and the Cloudflare rule.</li><li><strong>Some files 404 over HTTP</strong> — the <code>cstrike/</code> path level is missing or doubled in the web root; the client requests <code><url>/cstrike/maps/...</code> exactly.</li><li><strong>bz2 present but client still fetches raw file</strong> — harmless; you used <code>bzip2 -k</code> so both exist. Confirm the <code>.bz2</code> is the one being cached.</li><li><strong>High origin CPU during map change waves</strong> — nginx is re-compressing; ensure <code>gzip off</code> and that you serve the pre-made <code>.bz2</code> directly.</li></ul><h2>Verification</h2><p>Open the exact compressed URL in a browser and confirm it downloads and reports the right type:</p><pre>curl -I https://dl.example.com/cstrike/maps/de_rats.bsp.bz2</pre><p>Look for <code>Content-Type: application/x-bzip2</code> and, once behind the CDN, a <code>cf-cache-status: HIT</code> on the second request. Then delete a custom map from a test client, connect, and watch the loading-screen download finish in seconds. If it crawls, you are still serving uncompressed files or the CDN is missing them — recheck steps 1 and 4.</p> | |
| 0 | 18 |
