Source Engine Update Rate Tuning: cl_updaterate vs sv_maxupdaterate & Entity Limits

Why Clamping Matters

When you launch a Source‑based game, the client tells the server how often it wants to send command packets. That value is stored in cl_updaterate. The server, however, imposes a hard ceiling – sv_maxupdaterate. If the client asks for more packets per second than the server allows, the excess packets are simply dropped. The result is a smoother network experience that still keeps the simulation ticks in sync.

Mechanism in Action

During the initial handshake, the server broadcasts its sv_maxupdaterate to the client. Every tick the client compares the desired cl_updaterate against that value. If the requested rate is higher, the server clamps the effective rate to sv_maxupdaterate and discards packets that would exceed it. This protects the server from bandwidth spikes while still allowing the client to receive updates at the most frequent rate the server can handle.

Concrete Example

Assume a dedicated server running a CS:GO map has the following console settings:

# Server console
sv_maxupdaterate 64
sv_minupdaterate 64
sv_cmdrate 128

The client’s configuration file (config.cfg) might contain:

# Client config
cl_updaterate 128
cl_cmdrate 128
net_graph 1

When the client connects, the server will enforce sv_maxupdaterate 64. Even though cl_updaterate is set to 128, the server will only accept 64 packets per second. In the net_graph output you’ll see the updaterate field capped at 64, while the cmdrate remains at 128. The choke column may rise if the client’s command rate outpaces the server’s ability to process them.

Diagnosing with net_graph

Run the following in the client console while playing:

net_graph 1
net_graphmsg 1

Watch the values for updaterate, cmdrate, loss, and choke. A consistent choke of 0–10% is healthy. Values above 20% indicate the server is dropping packets because the cl_updaterate is too high relative to sv_maxupdaterate and the network bandwidth.

Entity Index Limits and Baseline Delta Compression

Source’s entity system uses an edict table that can hold up to 2048 entries. Every spawned object consumes one index. If you try to create more than 2048 entities, the server will wrap the index counter and start reusing old slots. This can cause unpredictable entity replacement, crashes, or hard‑to‑debug behavior.

Practical Test

From the server console, spawn 2050 dynamic entities and list them:

ent_create func_dynamic 0 0 0
... (repeat 2050 times) ...
ent_list

Observe that the first few indices (e.g., 1–10) reappear after the 2048 mark, indicating wrap‑around. Avoid scripts or mods that generate large numbers of temporary entities without cleanup.

Common Pitfalls

• Setting cl_updaterate above sv_maxupdaterate – No gameplay benefit; increases net_graph choke.
• Ignoring cmdrate vs updaterate balance – If cl_cmdrate is too high relative to cl_updaterate, the client will send more commands than the server can process, leading to choke.
• Overlooking avgPacketSize – The product updaterate × cmdrate × avgPacketSize must fit within the available bandwidth; otherwise you’ll see loss or choke spikes.
• Exceeding the 2048 edict limit – Causes entity index wrap‑around and server instability.

Best‑Practice Checklist

1. Set sv_maxupdaterate to a value that matches your server’s bandwidth capacity (common values: 64, 128).
2. Configure cl_updaterate on the client to the same number or lower; avoid higher values.
3. Keep cl_cmdrate at least equal to cl_updaterate; for many games, 128 is a safe default.
4. Enable net_graph 1 during testing; monitor choke and loss for stability.
5. Never spawn more than 2048 entities in a single map or gameplay session.

Conclusion

Properly aligning client and server update rates is essential for stable, low‑latency gameplay in Source engines. By respecting sv_maxupdaterate, balancing cl_updaterate and cl_cmdrate, and staying within the 2048 edict limit, you can avoid choke, packet loss, and server crashes.