Latency on a game server is decided mostly by physics and packet scheduling, not by the raw speed of your NIC. You can rent a 10 Gbps port and still give players 120 ms of rubber-banding if your UDP buffers are undersized, your kernel is running the wrong congestion control for a real-time workload, or your CPU is spending cycles on softirqs that should belong to the simulation thread. This guide walks through the network stack configuration that measurably reduces lag on a dedicated game host, with concrete sysctl values and the reasoning behind each.<\/p>\n\n\n\n
Linux ships defaults tuned for throughput on file servers and web workloads. That means large receive buffers, CUBIC congestion control, and aggressive interrupt coalescing. Every one of those choices trades latency for bandwidth. A game server does the opposite trade: packets are tiny (60-1400 bytes), the frame rate is 20-128 Hz, and the value of a packet decays to zero within one tick interval. A block-break acknowledgment that arrives 80 ms late is worthless even if it arrived on a perfectly efficient 10 Gbps link.<\/p>\n\n\n\n
The three levers that matter most are the UDP receive buffer, the NIC transmit queue length, and the softirq processing model. Fix those three and you will resolve the majority of “why does my server feel laggy when ping is fine” complaints. The rest \u2014 congestion control, MTU, checksum offload \u2014 are refinements that matter most at high player counts or on noisy uplinks.<\/p>\n\n\n\n
Under peak load, a game server can burst thousands of small UDP datagrams per second. If the socket receive buffer fills, the kernel silently drops packets \u2014 and for UDP there is no retransmit, so players simply miss state updates. Raise the ceiling first, then set the application buffer. Add these to Then set the buffer at the application level too. Most game servers accept a socket buffer config, but for anything you launch yourself, wrap it or set the socket option in the launcher. Verify effectiveness by watching Modern NICs batch interrupts to save CPU. That is great for a webserver and terrible for a game server, because it adds 50-200 microseconds of jitter to every packet. Disable coalescing on your game interface:<\/p>\n\n\n\n A too-short transmit queue causes drops under burst; a too-long one adds latency because packets sit in the queue. For game servers, 1000-2000 packets of queue length is the sweet spot. Set Set Leave MTU at 1500 unless your whole path supports jumbo frames. A fragmented game packet is a lost packet, because losing one fragment loses the whole datagram. Verify path MTU through the uplink your provider uses with Enable Do not tune blind. Baseline with \/etc\/sysctl.d\/99-game.conf<\/code>:<\/p>\n\n\n\n\n
net.core.rmem_max = 16777216<\/code> \u2014 allows a 16 MB max UDP receive buffer.<\/li>\nnet.core.wmem_max = 16777216<\/code> \u2014 matching send buffer ceiling.<\/li>\nnet.core.rmem_default = 2097152<\/code> \u2014 2 MB default for new sockets.<\/li>\nnet.core.netdev_max_backlog = 16384<\/code> \u2014 deeper queue before the kernel drops during bursts.<\/li>\nnet.core.somaxconn = 4096<\/code> \u2014 helps TCP game control channels (Steam, RCON).<\/li>\n<\/ul>\n\n\n\nnetstat -su<\/code> and checking the “receive buffer errors” counter during peak load \u2014 it should stay flat. If it climbs, your buffer is still too small or you have a CPU-side processing problem, not a network one.<\/p>\n\n\n\nInterrupt Coalescing Is Stealing Your Responsiveness<\/h2>\n\n\n\n
ethtool -C eth0 rx-usecs 0 tx-usecs 0 adaptive-rx off adaptive-tx off<\/code>. Then set the ring buffers to their maximum with ethtool -G eth0 rx 4096 tx 4096<\/code> (adjust to what ethtool -g eth0<\/code> reports as maximum). Also pin the NIC’s interrupt queues away from the cores running your game threads using irqbalance<\/code> exclusions or manual \/proc\/irq\/*\/smp_affinity<\/code> writes. On a 16-core box, dedicating cores 0-1 to network IRQ handling and leaving 2-15 for game instances keeps the tick loop clean.<\/p>\n\n\n\nTransmit Queue and Congestion Control<\/h2>\n\n\n\n
net.core.wmem_default<\/code> and use tc qdisc replace dev eth0 root fq_codel<\/code>. fq_codel<\/code> gives you fair queuing plus active queue management, which prevents a single burst of state syncs from adding bufferbloat latency to your tick packets.<\/p>\n\n\n\nnet.ipv4.tcp_congestion_control = bbr<\/code> if you run TCP-based game control or asset delivery alongside the game \u2014 BBR handles lossy uplinks far better than CUBIC and keeps RTT low under load. For pure UDP game traffic, congestion control does not apply, which is another reason to get the buffer and IRQ settings right instead of relying on TCP tuning. If your provider hands you 1 Gbps by default, verify you are not saturating it before blaming the stack \u2014 a saturated port drops indiscriminately regardless of qdisc.<\/p>\n\n\n\nMTU, Checksums, and Offloads<\/h2>\n\n\n\n
ping -M do -s 1472<\/code>. Keep checksum offload enabled \u2014 ethtool -K eth0 rx on tx on<\/code> \u2014 since software checksums burn CPU you want for the simulation thread.<\/p>\n\n\n\nnet.ipv4.udp_rmem_min<\/code> and net.ipv4.udp_wmem_min<\/code> to guarantee a floor for UDP socket memory even under pressure. And disable net.ipv4.tcp_slow_start_after_idle<\/code> if you run persistent control channels. These are the settings that separate a server that “pings 15 ms but lags” from one that feels instant.<\/p>\n\n\n\nTesting That Your Changes Actually Helped<\/h2>\n\n\n\n
mtr --report --udp<\/code> to a known-good external host, record tick-time percentiles from your game server’s own metrics, and log the 99th-percentile jitter. Apply one change at a time and re-measure. A 20% reduction in tick-time p99 is a real win; a change that only improves average ping by 2 ms with no p99 effect is not worth the complexity. Our bare-metal plans<\/a> give you full kernel and ethtool control, which a managed VPS will not.<\/p>\n\n\n\nWhere To Go From Here<\/h2>\n\n\n\n