RE:NODE

Networking11 min read

Game server bandwidth per player, by game

How much upload each player costs on Minecraft, Source games, Valheim, Arma 3, Factorio and more, the settings that change it, and how to size and measure server traffic.

0 readers

A player on a game server costs between about 5 and 250 KB/s of the server's upload, depending on the game: a few kilobytes a second for Minecraft or Terraria, 30-60 KB/s for a Source shooter at 64 tick, 50-150 KB/s for Valheim, and up to 250 KB/s for a busy Arma 3 mission. What each player sends back is far smaller, usually a few kilobytes a second. Steady-state traffic is rarely the problem; the bursts are - a player joining and downloading the world, a map change, a modded server pushing assets. This post gives the per-game numbers, the settings that move them, and how to measure what your own server actually sends.

For the monthly totals and what "unmetered" means, see bandwidth and fair use. This post stays with the per-player view.

Traffic per player, by game#

These are typical figures for the server's outbound traffic to one connected player, in steady play. They are ranges because the number depends on what is near the player, how fast they move and how the server is configured. Measure your own; use these to know whether your measurement is plausible.

GamePer player, server to clientWhat drives it
Minecraft Java5-20 KB/sView distance, entity count, how fast players move
Terraria5-15 KB/sProjectiles and NPCs on screen
Factorio10-30 KB/sPlayer actions, not factory size
Project Zomboid20-60 KB/sZombie population near the player
Source games at 64 tick (CS2, TF2, Garry's Mod)30-60 KB/sTick rate, player count, client rate
Survival sandboxes (7 Days to Die, DayZ)30-150 KB/sEntities and players in view
Valheim50-150 KB/sBuilt pieces and creatures in nearby zones
Arma 350-250 KB/sAI units, vehicles, basic.cfg limits

Two patterns stand out. Games that send the world state as it changes (Valheim, Arma, survival sandboxes) cost more per player than games that send compact, predictable updates (Minecraft, Terraria). And Factorio is the odd one out: it runs every client's simulation in lockstep and only sends player inputs, so a vast factory costs no more bandwidth than a small one - until someone joins and needs the whole map.

Outbound is the number that matters#

Traffic is not symmetric. Each player sends the server their inputs - movement, aim, actions - which is small and roughly constant, typically 2-10 KB/s. The server sends each player the state of everything around them, which grows with what is going on. Multiply that by the number of players and the server's upload is always the side that fills first.

That is why hosting at home runs into trouble on connections that look fast. A 250/25 line has plenty of download and 25 Mbit/s of upload, about 3 MB/s, shared with everything else in the house. Ten Valheim players at 100 KB/s is 1 MB/s before anybody upstairs starts a video call. Hosting a game server at home vs renting one covers that side. In a datacentre the uplink is not the constraint for a normal game server; the per-player numbers matter there mainly for understanding bursts and for spotting something wrong.

The bursts: joins, map changes and downloads#

Steady traffic is small. Most bandwidth complaints are about the moments when it is not.

Joining. A new player needs the world around them. A Minecraft client arriving in a fresh area pulls chunk data as fast as the connection allows, several megabytes in a few seconds. A Factorio client downloads the entire save before it can play - tens of megabytes for a large base, more for a megabase. Twenty players reconnecting after a restart all do this at once, which is why the minute after a restart is the busiest minute of the day.

Map changes. Source-engine servers send every connected client into a loading screen at once. If the map or its assets are not already on the clients, they have to be downloaded.

Content downloads. This is where the big numbers live, and where a configuration choice decides whether your server carries the load:

  • Garry's Mod and other Source games can serve custom content directly from the game server, which is slow and competes with gameplay, or from a FastDL web server set with sv_downloadurl, or from the Steam Workshop via resource.AddWorkshop in a Lua file, which makes clients download from Steam instead of you. Garry's Mod workshop and FastDL covers the setup.
  • Minecraft resource packs set with resource-pack= in server.properties are downloaded from the URL you give, not from the server. Host the file somewhere that can take the load and set resource-pack-sha1 so clients cache it.
  • FiveM streams custom vehicles, maps and clothing from the server to each player on join. A server with a few hundred megabytes of streamed assets sends a few hundred megabytes to every new player, and players arriving together share the uplink. Trim what you stream; FiveM MLO maps and streaming assets goes into how.
  • Factorio has its own limit for map downloads in server-settings.json: max_upload_in_kilobytes_per_second (0 means unlimited) and max_upload_slots, which caps how many players can download the map at once. On a home connection, setting these keeps a join from freezing everyone else's game.

The settings that move the number#

Most games give you a few levers. Pulling them trades visual range or update frequency for bandwidth, so use them to fix a real problem rather than by default.

Minecraft

view-distance (default 10) in server.properties is the big one: the number of chunks sent around each player grows with the square of it, so dropping from 10 to 8 removes about a third of the chunk data. simulation-distance affects CPU, not bandwidth. network-compression-threshold (default 256) compresses any packet larger than that many bytes; lowering it saves a little bandwidth at a CPU cost, and -1 turns compression off, which only makes sense behind a proxy on the same machine. Paper adds per-player chunk-sending rate limits in paper-global.yml; the key names have changed between versions, so check the file your build generated. Paper optimisation covers the rest.

Source-engine games

Traffic to each client is capped by the client's rate setting (bytes per second) and bounded by the server's sv_minrate and sv_maxrate. In Source 1 games such as TF2 and Garry's Mod, sv_maxupdaterate limits how many updates per second each client receives. CS2 changed the networking model and removed several of the old per-client update cvars, so a CS:GO-era config does not translate line for line - check which settings your game still honours. Raising the tick rate in games that allow it roughly scales traffic with it: 128 updates a second cost about twice what 64 do. What tick rate actually means explains the trade.

Arma 3

Arma is explicitly tunable through basic.cfg. The keys are MaxMsgSend, MaxSizeGuaranteed, MaxSizeNonguaranteed, MinBandwidth, MaxBandwidth, MinErrorToSend and MinErrorToSendNear. MinBandwidth and MaxBandwidth tell the server what it can assume about its own connection, and setting MaxBandwidth far below the real capacity is a classic cause of desync on a server with headroom to spare. MinErrorToSend controls how far an object may drift before an update is sent; smaller values mean smoother distant movement and more traffic. Change one at a time and test with a full mission.

Valheim

Vanilla Valheim has no bandwidth setting. Its built-in send rate is conservative, which is one reason large groups see rubber-banding near busy bases. Community mods exist that raise the limit and compress traffic, and they have to be installed on the server and usually on every client. Valheim performance and lag explains where bandwidth fits among the other causes.

Spectators, proxies and relays#

Players are not the only thing a server sends to. Three other consumers are easy to forget when you add up traffic.

Spectator relays. Source-engine servers can run SourceTV (GOTV in Counter-Strike), which is effectively an extra client that receives the full game state and rebroadcasts it to spectators. The game server sends one stream to the relay; the relay then sends a stream to every spectator. On a single machine running both, every spectator costs about as much as a player. tv_maxclients caps how many can watch directly, and a tournament with a large audience should push spectators to separate relays rather than the match server. CS2 GOTV and demos covers the settings.

Proxies in front of the server. A Minecraft network behind Velocity or BungeeCord carries every byte twice on the proxy machine: in from the backend, out to the player. If the proxy and backends share a host, the backend-to-proxy leg stays local and costs nothing on the uplink; if they are on separate machines, it does. The same applies to any tunnel or relay you put in front of a home server - the relay's traffic is the server's traffic plus the same again in the other direction. Tunnels and proxies for game servers goes into what else a relay costs.

Status queries and monitoring. Every server list site, status bot and scanner that queries your server adds a small, steady trickle. On a normal day it is negligible. During a query flood it is not, and it shows up as outbound traffic with no players online. Query ports and A2S explains what is being asked and answered.

Sizing an upload for a player count#

The arithmetic is simple: players times the per-player figure, plus headroom for joins and bursts. A factor of 1.5 is a sensible margin for steady play; more if your server does content downloads from the game port.

ServerSteady outboundWith 1.5x headroom
10 players on Minecraft at 15 KB/s150 KB/s, 1.2 Mbit/s1.8 Mbit/s
10 players on Valheim at 100 KB/s1 MB/s, 8 Mbit/s12 Mbit/s
24 players on TF2 at 45 KB/s1.1 MB/s, 8.6 Mbit/s13 Mbit/s
32 players on Project Zomboid at 40 KB/s1.3 MB/s, 10 Mbit/s15 Mbit/s
60 players on Arma 3 at 120 KB/s7.2 MB/s, 58 Mbit/s86 Mbit/s

Remember the conversion: 1 MB/s is 8 Mbit/s. Connection speeds are quoted in bits, game traffic is usually measured in bytes, and mixing them up gives answers that are eight times wrong.

For a home server, compare the last column with your measured upload under load, not the figure on the contract. For a hosted server, these numbers are well within any normal uplink. On RE:NODE bandwidth is unmetered - not billed per gigabyte - which covers any game server used normally; it is not a licence to run something that saturates a shared uplink, and bandwidth and fair use is plain about where that line is.

Measuring what your server actually sends#

Estimates are fine for planning. When something is wrong, measure.

On a Linux machine or VDS you control:

bash
# Live totals per interface, refreshed every second$ vnstat -l -i eth0# Live traffic per remote address - who is the server talking to?$ sudo iftop -i eth0 -P# Live traffic per process$ sudo nethogs eth0

Divide the outbound rate by the number of connected players and compare it with the table above. A server sending ten times the expected amount per player is doing something: serving downloads from the game port, a plugin sending far too many updates, or answering a flood of query packets. iftop shows which; if most of the traffic goes to addresses that are not players, it is not gameplay. What we do about attacks describes what a query flood looks like.

In the game itself, Source 1 games have net_graph 1 on the client, which shows incoming and outgoing rates and loss. Ask a player to read the numbers out while things are busy; it tells you what one client is actually receiving.

When bandwidth is not the problem#

Most "lag" on a hosted server is not bandwidth. A rough way to tell:

  • Everyone lags at once, and the server's CPU is high. The server is missing ticks. That is a CPU problem; see CPU vs RAM for game servers.
  • One player lags and others are fine. Their connection: wifi, a congested home uplink, packet loss on their route.
  • Lag spikes when someone joins. Could be bandwidth on a home server; on a hosted one, more often the CPU cost of loading chunks or areas for the new player.
  • Rubber-banding near busy areas only. Entity load or, in Valheim, a player with a poor connection owning the zone.

Latency, jitter and packet loss explains how to tell which of those you are looking at in about a minute.

FAQ#

How much upload do I need to host a Minecraft server?

For a small group, very little: 10 players need about 1.2 Mbit/s steady and a few times that while new chunks are streaming. A 10 Mbit/s upload is enough for most friend groups, provided the household is not using it heavily at the same time.

Does a bigger world use more bandwidth?

Not by itself. Bandwidth depends on what is near each player, not on how large the world is. A bigger world uses more disk and, if players spread out, more CPU and memory. Factorio is the exception for joins, where the whole save is downloaded.

Why does traffic spike after a restart?

Every player reconnects at once and downloads the area around them, or in some games the whole map. That burst is normal and short. If it causes problems at home, stagger reconnects or limit download rates where the game allows it.

Do mods increase bandwidth?

Mods that add entities, effects or frequent updates increase steady traffic. Mods that add content increase join traffic when clients have to download it. Mods that only change server logic usually add nothing.

Is 100 Mbit/s enough for a game server?

For one normal game server, comfortably. Even a busy Arma 3 server rarely needs more than a few tens of megabits at peak. What a host's network gives you beyond that is headroom for bursts and for absorbing traffic you did not ask for.


Comments

Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.

0/2000