Bandwidth Math: How Much Traffic Does a 32-Slot Server Use?

"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 (cl_updaterate, capped by sv_maxupdaterate) and how big each update is allowed to be (rate, capped by sv_maxrate). Here is the calculation, with realistic numbers and the caveats that make it an estimate rather than a promise.

1. The per-client formula

Outbound traffic to one client is, roughly:

bytes_per_second = snapshot_size_bytes * updates_per_second

The engine will never exceed the client's rate (bytes/second), so rate is a hard ceiling on that product. In practice a snapshot on a busy public server is on the order of 100–200 bytes after delta-compression, depending on how many players are visible and how much is moving.

2. Worked example: one player

Take a common competitive-ish setup — cl_updaterate 100, a snapshot around 150 bytes:

150 bytes * 100 /s = 15,000 bytes/s = ~15 KB/s down per player
15 KB/s * 8 = 120 kbps per player

Note this sits comfortably under a rate 25000 ceiling, so rate is not the limiter here; the update rate and snapshot size are. Drop the client to cl_updaterate 60 and the same math gives ~9 KB/s. Push a chaotic mod where every snapshot is near the rate cap and you approach 25 KB/s.

3. Scale to 32 slots

Multiply by the player count for the outbound total the server pushes:

32 players * 15 KB/s = 480 KB/s down
480 KB/s * 8 = ~3.8 Mbps outbound (server -> players)

So a full 32-slot server at 100 updates/s lands around 2.5–5 Mbps outbound depending on snapshot size. Inbound (client commands, governed by cl_cmdrate) is much smaller — client command packets are tiny — so figure inbound at roughly a quarter to a third of outbound, on the order of 1–1.5 Mbps. The server's uplink is the number that matters, because that is the direction that saturates first.

4. Mods change everything

The 150-byte figure is for standard gameplay. Traffic scales with how much state is in flight:

• Zombie / deathmatch / 100-player mods — more visible entities, more movement, bigger snapshots. Budget higher, and cap it with sv_maxrate or the uplink melts.
• Custom models and sprites — irrelevant to steady-state rate, but the initial download per join is large; that is a FastDL concern, not a snapshot-rate one.
• Higher sv_maxupdaterate — raising the cap lets clients pull more updates, multiplying the whole calculation.

5. Turn Mbps into a monthly total

Hosts bill on transfer, so convert sustained rate to a month of full play. Take 4 Mbps outbound sustained:

4 Mbps / 8 = 0.5 MB/s
0.5 MB/s * 3600 = 1.8 GB/hour
1.8 GB/hour * 24 * 30 = ~1.3 TB/month at 100% full, 24/7

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 uplink in Mbps first and the monthly cap second.

Common mistakes

• Budgeting on rate alone — rate is a ceiling, not the actual usage. Actual usage is snapshot size times updaterate, usually well below the ceiling.
• Forgetting the server caps clients — a client asking for cl_updaterate 1000 only gets what sv_maxupdaterate allows, so your math uses the server cap.
• Assuming symmetric traffic — outbound dwarfs inbound. Size the uplink, not the downlink.
• Ignoring the mod — a zombie server can double or triple these figures. Measure, do not assume.

Verification

Do not trust the estimate — measure it. On the server box, watch the interface counters while the server fills:

vnstat -l -i eth0
# or, live per-second:
ifstat 1

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 choke and loss on the scoreboard. Once measured, size the host uplink with headroom (2–3x the peak) so a full server never saturates the pipe.