How to Tune Linux Network Stack for High-Frequency Game Server Packets

• 01 / Measure
• 02 / Locate the bottleneck
• 03 / Change one setting
• 04 / Compare and retain

High-frequency game traffic often consists of many small updates rather than large downloads. A server can use little bandwidth while struggling to process packets on time. Players may notice delayed actions or rubber-banding even when a speed test looks healthy.

This guide covers Linux hosts running UDP-based multiplayer services. Confirm your game’s transport first: some games and supporting services use TCP or other protocols. These examples explain a diagnostic workflow; they are not benchmarks from an Onlive Server deployment.

This guide covers Linux hosts running UDP-based multiplayer services. If you are choosing a host, compare Linux dedicated server hosting for hardware resources and administrative access before planning network changes. Confirm your game’s transport first: some games and supporting services use TCP or other protocols. These examples explain a diagnostic workflow; they are not benchmarks from an Onlive Server deployment.

1. Record a baseline before Linux network stack tuning

Choose a repeatable workload: the same game build, map, mods, player count and traffic pattern. Record server tick duration alongside packet loss, jitter and application-measured response times. Compare the median with the 95th or 99th percentile so occasional stalls do not disappear inside an average.

Tick rate and packet rate are different. A hypothetical 64-tick simulation has about 15.6 milliseconds per tick, calculated as 1,000 ÷ 64. That does not mean every player sends exactly 64 packets per second, or that the host can spend the whole interval on networking.

uname -r
ip -br link
ip route show default

# Replace eth0 after identifying the game-traffic interface.
GAME_IFACE=eth0
ip -s link show dev "$GAME_IFACE"
ethtool -i "$GAME_IFACE"
ss -u -a -n -m

A default route is a starting point, not proof of the interface used by every player. Multi-homed hosts, containers and tunnels may take different paths. Run socket and protocol checks in the network namespace containing the game process; host NIC statistics describe a different layer.

For a regional starting point, use Onlive Server’s IP latency test page to review the available testing options. Compare those results with measurements from actual player networks. A default route is a starting point, not proof of the interface used by every player. Multi-homed hosts, containers and tunnels may take different paths. Run socket and protocol checks in the network namespace containing the game process; host NIC statistics describe a different layer.

2. Find where game packets are dropping or waiting

Capture counters before and after the same test interval. An old cumulative error count does not prove that the current configuration is failing.

# Absolute counters; repeat and compare the difference.
nstat -asz UdpInDatagrams UdpInErrors UdpRcvbufErrors UdpSndbufErrors
nstat -asz Udp6InDatagrams Udp6InErrors Udp6RcvbufErrors Udp6SndbufErrors

# Driver statistics and interrupt distribution.
ethtool -S "$GAME_IFACE"
cat /proc/interrupts

# Requires the sysstat package; samples every second, 10 times.
mpstat -P ALL 1 10

The nstat manual documents these counter options. Check IPv6 when your service uses it. Some counters or driver statistics may be unavailable; missing output is not a zero measurement.

The nstat manual documents these counter options. Check IPv6 when your service uses it. Some counters or driver statistics may be unavailable; missing output is not a zero measurement.

UdpInErrors is broader than a single cause. Do not add it to receive-buffer errors as though they were independent losses. See the kernel’s SNMP counter documentation for error accounting. Interface drops also need driver context; similarly named counters can mean different things.

UdpInErrors is broader than a single cause. Do not add it to receive-buffer errors as though they were independent losses. See the kernel’s SNMP counter documentation for error accounting. Interface drops also need driver context; similarly named counters can mean different things.

3. Tune UDP socket buffers only when evidence supports it

net.core.rmem_max limits ordinary receive-buffer requests; net.core.wmem_max does the same for sending. Raising a maximum does not automatically enlarge an existing game socket. The application must request an appropriate buffer, usually through its configuration or socket options.

Linux doubles the value supplied through SO_RCVBUF for bookkeeping, and reports that doubled value when queried. Account for this when comparing configuration with observations. The socket manual explains these semantics.

Linux doubles the value supplied through SO_RCVBUF for bookkeeping, and reports that doubled value when queried. Account for this when comparing configuration with observations. The socket manual explains these semantics.

sysctl net.core.rmem_max net.core.wmem_max
sysctl net.core.rmem_default net.core.wmem_default
sysctl net.ipv4.udp_mem
ss -u -a -n -m

In ss -m output, inspect the receive-buffer limit and current memory use for the game’s socket, not an unrelated service. A growing queue may mean the application cannot keep up. The ss manual defines the memory fields.

In ss -m output, inspect the receive-buffer limit and current memory use for the game’s socket, not an unrelated service. A growing queue may mean the application cannot keep up. The ss manual defines the memory fields.

A reversible receive-limit experiment

Suppose the application’s documented requirement is a 4 MiB receive-buffer request, its current permitted maximum is lower, and receive-buffer errors rise during bursts. The following example raises only that ceiling. The number is an illustrative test condition, not a recommended default for every game.

# Save this value in your change record as well.
GAME_OLD_RMEM_MAX=$(sysctl -n net.core.rmem_max)
printf 'Original rmem_max: %s\n' "$GAME_OLD_RMEM_MAX"

# Raise only if the existing ceiling is below this test value.
if [ "$GAME_OLD_RMEM_MAX" -lt 4194304 ]; then
  sudo sysctl -w net.core.rmem_max=4194304
fi

# Now use the game's documented receive-buffer setting,
# apply/restart it as required, and repeat the same workload.

# Roll back in this same shell after the test.
sudo sysctl -w "net.core.rmem_max=$GAME_OLD_RMEM_MAX"

Also restore the application’s buffer setting and recreate its sockets as required. Lowering the ceiling alone does not resize an already enlarged socket. Keep a record of the old value if you close the shell.

A buffer can absorb a burst; it cannot repair sustained overload. Excessive buffering can keep stale updates waiting longer. Leave udp_mem alone unless aggregate UDP memory pressure is demonstrated: its values are pages, not bytes, and its defaults reflect available memory. See the kernel UDP sysctl reference.

A buffer can absorb a burst; it cannot repair sustained overload. Excessive buffering can keep stale updates waiting longer. Leave udp_mem alone unless aggregate UDP memory pressure is demonstrated: its values are pages, not bytes, and its defaults reflect available memory. See the kernel UDP sysctl reference.

4. Check receive queues and CPU placement

Receive Side Scaling (RSS) distributes network flows across hardware receive queues. Receive Packet Steering (RPS) distributes later processing in software. Receive Flow Steering (RFS) adds application locality. These mechanisms can spread work, but enabling all of them is not automatically faster.

Inspect queue counts and interrupt distribution before changing CPU affinity. Keep the NIC’s NUMA locality in mind on multi-socket hosts. Avoid putting a busy receive queue on the same overloaded CPU as a critical game thread. RPS adds cross-CPU work, so evaluate whether it helps when hardware RSS already distributes traffic.

A single flow may remain on one queue; adding queues does not guarantee that one hot flow will spread across every core. Manual IRQ settings can also conflict with irqbalance. Use the kernel’s network scaling guide to plan a topology-specific change instead of copying a CPU mask from another server.

A single flow may remain on one queue; adding queues does not guarantee that one hot flow will spread across every core. Manual IRQ settings can also conflict with irqbalance. Use the kernel’s network scaling guide to plan a topology-specific change instead of copying a CPU mask from another server.

ethtool -l "$GAME_IFACE"
ethtool -x "$GAME_IFACE"
lscpu
cat /proc/interrupts

When backlog and NAPI limits matter

net.core.netdev_max_backlog caps an input backlog. net.core.netdev_budget and net.core.netdev_budget_usecs constrain polling work by packets and time. Larger budgets may improve receive processing while leaving less CPU time for the game.

Change these only after tracing backlog pressure or polling limits, and compare tick timing afterward. A large backlog is not a substitute for sufficient processing capacity. Definitions are in the kernel network sysctl documentation.

Change these only after tracing backlog pressure or polling limits, and compare tick timing afterward. A large backlog is not a substitute for sufficient processing capacity. Definitions are in the kernel network sysctl documentation.

5. Review interrupt coalescing, rings and offloads

Interrupt coalescing batches notifications. Reducing it can reduce waiting, but increase interrupts and CPU cost. Inspect the existing settings, then test one supported parameter with the driver’s guidance. Do not assume that disabling adaptive coalescing or setting every delay to zero improves tail latency.

ethtool -c "$GAME_IFACE"
ethtool -g "$GAME_IFACE"
ethtool -k "$GAME_IFACE"

A larger receive ring can absorb bursts but consumes resources and may permit more queued work. Record the original settings before an experiment; unsupported operations are common on virtual NICs. The ethtool manual describes inspection and modification options.

Keep checksum and segmentation offloads at their working defaults unless a specific problem justifies a test. GRO and GSO reduce per-packet work in supported paths; turning them off can raise CPU demand. Their effect depends on protocol and driver support, as described in the kernel offload documentation.

A larger receive ring can absorb bursts but consumes resources and may permit more queued work. Record the original settings before an experiment; unsupported operations are common on virtual NICs. The ethtool manual describes inspection and modification options.

Keep checksum and segmentation offloads at their working defaults unless a specific problem justifies a test. GRO and GSO reduce per-packet work in supported paths; turning them off can raise CPU demand. Their effect depends on protocol and driver support, as described in the kernel offload documentation.

6. Check packet size and the outbound path

Avoid relying on IP fragmentation for gameplay datagrams. Account for IP, UDP and any tunnel overhead when choosing payload size. A local MTU of 1,500 bytes does not establish the path MTU to every player, and jumbo frames on the server do not make the public internet a jumbo-frame path.

Linux UDP uses path MTU discovery by default and can report EMSGSIZE when a write exceeds the known limit. The application must handle the result. Consult the UDP manual and test real player paths, including IPv6 where applicable.

Linux UDP uses path MTU discovery by default and can report EMSGSIZE when a write exceeds the known limit. The application must handle the result. Consult the UDP manual and test real player paths, including IPv6 where applicable.

Inspect local egress queues when latency rises during uploads or backups:

tc -s qdisc show dev "$GAME_IFACE"

FQ-CoDel combines flow scheduling with queue-delay control. It can help in appropriate local egress conditions, but it cannot fix a queue outside the host and does not itself set a bandwidth shaping rate. Review the FQ-CoDel manual before designing a change. Do not replace an existing traffic-control hierarchy without understanding it.

FQ-CoDel combines flow scheduling with queue-delay control. It can help in appropriate local egress conditions, but it cannot fix a queue outside the host and does not itself set a bandwidth shaping rate. Review the FQ-CoDel manual before designing a change. Do not replace an existing traffic-control hierarchy without understanding it.

Keep TCP and UDP tuning separate

BBR is a TCP congestion-control option. Changing net.ipv4.tcp_congestion_control does not tune raw UDP gameplay traffic. TCP connection backlogs and TCP_NODELAY belong to TCP investigations. Identify which transport carries the delayed action before applying a tuning guide.

Keep firewall and upstream DDoS protection in place. If traffic disappears during filtering, inspect rule counters and consult the provider. Disabling protection is not a network-performance strategy.

7. Validate improvements before making them permanent

Repeat the baseline workload after each change. Keep a setting only when the target problem improves without worse tick timing, CPU pressure, memory use or packet age. Re-test at peak load; a quiet server can hide the cost of extra interrupts.

• Compare like with like: player count, map, software version, duration and source networks.
• Track outcomes: error-counter deltas, queue growth, game response percentiles and tick duration.
• Keep rollback details: old kernel value, application setting, NIC state and the exact change.
• Check persistence: reboots, interface resets and service restarts may alter the effective configuration.

For an accepted sysctl change, place only the validated key and value in a dedicated file such as /etc/sysctl.d/90-game-network.conf. Check existing configuration for conflicts. Apply that file with sudo sysctl -p /etc/sysctl.d/90-game-network.conf, verify the running value, then verify again after a planned reboot. See the sysctl manual.

To reverse a persistent change, remove its entry and explicitly restore the recorded runtime value. Removing a file does not undo the running setting. NIC changes need their own distribution-supported persistence and rollback process.

For an accepted sysctl change, place only the validated key and value in a dedicated file such as /etc/sysctl.d/90-game-network.conf. Check existing configuration for conflicts. Apply that file with sudo sysctl -p /etc/sysctl.d/90-game-network.conf, verify the running value, then verify again after a planned reboot. See the sysctl manual.

If you need help reviewing the change, check the scope of Onlive Server’s Linux administration services and confirm whether game-network troubleshooting is covered. To reverse a persistent change, remove its entry and explicitly restore the recorded runtime value. Removing a file does not undo the running setting. NIC changes need their own distribution-supported persistence and rollback process.

Frequently asked questions

What are the best Linux network settings for a game server?

There is no universal preset. Match changes to evidence from the game socket, NIC queues, CPU load and player measurements. Kernel version, hardware and the game engine affect the result.

Will a bigger UDP buffer reduce lag?

It may prevent drops during short bursts when the existing buffer is insufficient. It can also let old packets wait longer if the application is overloaded. Compare delay and loss together.

Does BBR improve UDP game packets?

BBR configured through the Linux TCP sysctl applies to TCP. It does not change the handling of raw UDP packets. A game’s application-level transport may implement its own congestion control.

Can I tune networking on a VPS?

You may control some guest settings, but physical NIC queues, host scheduling and other limits can remain with the provider. Confirm the available controls and distinguish guest problems from host contention.

Can I tune networking on a VPS?

With Linux VPS hosting, you may control some guest settings, but physical NIC queues, host scheduling and other limits can remain with the provider. Confirm the available controls and distinguish guest problems from host contention.

Can Linux tuning guarantee lower player ping?

No. Host tuning can address local delays. Distance, carrier routing, congestion and the player’s connection still affect response time. Measure from the regions your players use.