GR
Gear-Rank main navigation
Back

Network Guide

Bufferbloat Fix & Network Tuning for CS2 & Valorant

Your average idle ping can read 15 ms while gameplay still feels inconsistent. The underlying issue is often Bufferbloat: packet queues backing up inside your router or ISP hardware during concurrent traffic. This guide diagnoses Bufferbloat via Waveform, compares stock router QoS with OpenWrt CAKE, and covers the small driver-level tweaks that matter only after the queue problem is solved. Priority order: wired connection, then SQM, then driver tuning.

D
Daniel P. - Hardware expert
  • 15 min read
Share

What Bufferbloat Is and Why It Hurts CS2 & Valorant

What Bufferbloat Is and Why It Hurts CS2 & Valorant

Bufferbloat is transient latency inflation caused by unmanaged packet queues inside routers and modems. When traffic approaches link capacity (a background download, a Discord screen share, an OBS broadcast, a cloud backup), networking equipment holds excess packets in memory buffers to avoid dropping them. Game packets from CS2 or Valorant do not bypass this queue; they wait behind large bulk TCP packets. During queue saturation, transit latency for individual game packets can spike by 40-150 ms or more.

How it shows up in each game:

Counter-Strike 2 (official Valve servers) runs at 64 ticks (15.625 ms per tick) and timestamps player inputs with sub-tick precision on the client. Queue delay and jitter change when those inputs reach the server relative to the tick they belong to, so shots and movement are resolved less predictably and your ping graph becomes uneven. The practical symptoms are ping spikes, packet delivery anomalies and "I shot first" moments.

Valorant runs at 128 ticks (7.8125 ms per tick) with server-authoritative gameplay and client-side prediction. When packets arrive late or are lost, the client has to be corrected by the server, which players experience as rubberbanding and position snapping. Riot's own Network Buffering setting exists precisely because too little buffering causes server-predicted moves and client corrections, while too much adds latency and increases peeker's advantage.

Upload vs Download Queue Locations: • Upstream Bufferbloat: accumulates in your local router's transmit queue when outbound data saturates your upload link. Outgoing game inputs wait behind upload transfers. This is directly under your control via local router shaping. • Downstream Bufferbloat: accumulates upstream inside ISP equipment (CMTS, DSLAM or fiber OLT) when inbound traffic saturates your download link. A local router cannot drain the ISP's queue directly; instead it must implement ingress traffic shaping (dropping or ECN-marking inbound packets at roughly 90-95% of capacity on typical lines) to force remote TCP senders to slow down before the ISP buffer fills up.

How to Diagnose Bufferbloat in 2 Minutes (Free Test)

Before modifying router settings, measure your idle ping against loaded ping. Waveform's test isolates latency increases across separate upload and download stress phases. As a cross-check you can also use Cloudflare's speed test, which reports loaded latency.

  1. 1Run the Waveform Bufferbloat Test

    What to do:

    1. Connect via wired Ethernet. Testing over Wi-Fi reflects wireless airtime contention rather than router queue bloat.

    2. Close background applications (Steam, game launchers, browser tabs, cloud sync) and disable any VPN or traffic-modifying browser extension.

    3. Open waveform.com/tools/bufferbloat and click Start Test.

    4. Review the results: Unloaded Baseline vs Loaded Latency across both Download and Upload phases.

    • Grade A+ (+0-5 ms added latency): negligible buffer delay.

    • Grade A (+5-30 ms): minimal queue buildup. Fine for most players; the delta only appears while the link is saturated, so it matters mainly if you stream or download while gaming.

    • Grade B (+30-60 ms): noticeable queue bloat during concurrent traffic. QoS or SQM configuration is recommended.

    • Grade C (+60-200 ms): severe bufferbloat. Expect lag spikes whenever any background transfer is active.

    • Grade D (+200-400 ms): critical queue bloat.

    • Grade F (>400 ms): unmanaged FIFO buffering. Traffic shaping is strongly recommended for competitive play.

    Always run this test over a wired connection from your gaming PC. Wi-Fi retransmissions distort queue measurements.

  2. 2Verify In-Game Network Telemetry in CS2

    CS2 replaced net_graph with a telemetry HUD (Settings → Game → Telemetry). The matching console commands take 0 (never), 1 (only when conditions are poor) or 2 (always):

    • cl_hud_telemetry_ping_show 2 (ping)

    • cl_hud_telemetry_net_misdelivery_show 2 (packet loss and out-of-order delivery)

    • cl_hud_telemetry_frametime_show 2 (frame pacing, to separate rendering hitches from network spikes)

    • cl_hud_telemetry_serverrecvmargin_graph_show 1 (graph of how early or late your input packets reach the server; useful for spotting jitter)

    Test procedure: start a continuous download or video stream on another device and join a server.

    • If in-game ping rises by 20+ ms during background traffic or the misdelivery indicator flashes: local Bufferbloat is likely.

    • If telemetry stays flat under local load: the spikes come from upstream routing or server congestion, not your router queue.

  3. 3Check NIC DPC Latency with LatencyMon

    What to do:

    1. Download and run LatencyMon (free utility from resplendence.com).

    2. Click Start Monitoring and play a deathmatch or custom game for 3-5 minutes.

    3. Open the Drivers tab and inspect execution times for your network adapter's vendor driver (for example rt640x64.sys for Realtek, e2f.sys or igc64.sys for Intel) as well as ndis.sys, which is the generic wrapper and often not the actual culprit.

    • Reference: repeated DPC spikes of several hundred microseconds on the NIC driver suggest power saving or aggressive interrupt moderation is delaying packet processing. Look at how often spikes occur, not only the single highest value.

    • If the NIC driver is clean, skip the NIC Driver Tuning section: the gain will be negligible.

Quick Fix: Router QoS Bandwidth Limiting (Stock Firmware)

Bandwidth limiting on stock router firmware works by shifting the bottleneck: by capping WAN throughput below your measured line speed, you stop the ISP's oversized buffer from filling up. However, a simple rate limit does not remove queues entirely; it moves the queue into your router. Unless the firmware includes Active Queue Management (like fq_codel), a plain FIFO shaper can still build internal delay under heavy load. Results vary by manufacturer and firmware version and must be verified with Waveform. If your ISP-supplied modem/router has no usable QoS, put it in bridge mode (or use your own router behind it) so shaping can be done on a device you control.

  1. 1Measure Your Actual Line Speed (Not Advertised Plan Speed)

    How to measure:

    1. Connect via wired Ethernet with all other network devices idle.

    2. Run three separate speed tests via speedtest.net or fast.com.

    3. Record the lowest measured Upload and Download throughput in Mbps.

    • Example: ISP plan is 100/20 Mbps. Measured throughput is 92 Mbps download / 18.5 Mbps upload.

    • Base your QoS calculations on real numbers (92 / 18.5), never on the advertised plan speed.

  2. 2Configure Upload and Download Bandwidth Limits

    Where to configure in common router interfaces (menu names vary by model and firmware version):

    • ASUS: QoS → choose Adaptive QoS or Traditional QoS (not 'Bandwidth Limiter', which is a per-client throttle) → enter manual Upload and Download limits. Asuswrt-Merlin additionally offers fq_codel and CAKE options; stock firmware does not necessarily.

    • TP-Link: Advanced → QoS → Enable QoS → set total upload/download bandwidth.

    • NETGEAR: QoS menus differ a lot between models; look for manual upstream/downstream limits.

    • Starting point (92/18.5 Mbps example):

    - Download limit: roughly 83-87 Mbps (90-95% of 92 Mbps)

    - Upload limit: roughly 16.6-17.6 Mbps (90-95% of 18.5 Mbps)

    • Adjust by connection type: stable fiber can often go higher (95%+), while cable (DOCSIS), LTE/5G and satellite connections with fluctuating speeds usually need lower limits.

    • Warning: enabling software QoS on stock routers generally disables Hardware NAT / Flow Acceleration. On connections above 400-500 Mbps this can cap routing throughput if the router CPU is weak.

    A limit at 100% of line speed does not prevent queue buildup. Start around 90-95%, run Waveform, and lower in small steps until loaded latency stops climbing.

  3. 3Prioritize Your Gaming PC by IP / MAC Address

    Configure device prioritization (only useful on routers without CAKE/fq_codel; with CAKE it is not needed):

    1. Assign your gaming PC a static DHCP reservation in your router's LAN settings.

    2. In the router QoS rules, assign Highest / High Priority to your gaming PC's MAC address or IP.

    • Why device priority beats port priority: CS2 matchmaking traffic can be routed through Steam Datagram Relay (SDR) and Valorant through Riot Direct, so port numbers are not a reliable way to identify game traffic. MAC/IP priority covers everything from your PC.

    • Note on WMM: WMM (Wi-Fi Multimedia) is an 802.11e wireless QoS protocol; it has zero effect on wired Ethernet ports.

Advanced Fix: CAKE SQM on OpenWrt (Optimal Solution)

CAKE (Common Applications Kept Enhanced) is an Active Queue Management (AQM) system that combines deficit-mode fair queuing (DRR++) with the Cobalt AQM algorithm (an enhanced synthesis of CoDel and BLUE). Instead of one FIFO queue, CAKE isolates traffic into sub-queues by flow (and optionally by host), so small latency-sensitive UDP packets such as game traffic are not stuck behind bulk TCP transfers, with no manual port rules. CAKE has been in the mainline Linux kernel since 4.19 and is supported in OpenWrt through the SQM packages.

  1. 1Hardware Considerations & Router Compatibility

    Router requirements for CAKE:

    1. Check OpenWrt support for your model at openwrt.org/toh/start (Table of Hardware).

    2. CPU workload: CAKE runs per-packet hashing and queue management in CPU software. Older single-core MIPS routers (e.g. TP-Link Archer C7) typically bottleneck around 100-150 Mbps with SQM active. For 500M-1G connections, use a modern quad-core ARM router (such as the GL.iNet GL-MT6000 Flint 2) or an x86 mini PC.

    3. Hardware Offloading: in OpenWrt (Network → Firewall), disable Software/Hardware Flow Offloading on setups running SQM, because offloading bypasses the Linux network stack where CAKE operates.

    Flashing third-party firmware carries bricking risks. Follow OpenWrt's exact installation instructions for your hardware revision.

  2. 2Install and Configure SQM with CAKE in LuCI

    Package installation:

    • OpenWrt 25.12 and newer (apk): apk update && apk add sqm-scripts luci-app-sqm

    • OpenWrt 24.10 and older (opkg): opkg update && opkg install sqm-scripts luci-app-sqm. Note that the 24.10 series reached end of life in September 2026, so upgrading to 25.12 is recommended.

    LuCI Web GUI configuration (Network → SQM QoS):

    1. Basic Settings:

    • Enable: checked

    • Interface name: your actual WAN interface ('wan' / eth0 for DHCP or static; 'pppoe-wan' for PPPoE)

    • Download Speed: roughly 90-95% of measured speed in kbit/s (e.g. 90000 for 100 Mbps)

    • Upload Speed: roughly 90-95% of measured speed in kbit/s (e.g. 18000 for 20 Mbps)

    2. Queue Discipline tab:

    • Queue discipline: cake

    • Queue setup script: piece_of_cake.qos

    3. Link Layer tab:

    • Link Layer: 'Ethernet with overhead' (or 'ATM' for legacy ADSL)

    • Overhead: 18 for plain Ethernet/DOCSIS-style links; PPPoE over Ethernet adds about 8 bytes (26); DSL and some fiber types have their own values, so check the OpenWrt SQM documentation for your link type.

    4. Optional (Advanced tab): add 'nat dual-srchost' for egress and 'nat dual-dsthost ingress' for ingress options so bandwidth is shared fairly between hosts on your LAN.

    5. Click Save & Apply.

    For LTE/5G or satellite links whose speed fluctuates, consider the cake-autorate package, which adjusts the shaper rate dynamically.

  3. 3Validate Queue Behavior with Waveform

    Verification:

    1. Re-run the Waveform Bufferbloat test.

    2. Typical result: Grade A or A+, with loaded latency staying within a few milliseconds of baseline in both phases. Results depend on your line stability.

    3. Fine-tuning: if loaded latency still rises during the upload phase, reduce the upload limit by 2-3% increments and retest.

Connection Medium: Wi-Fi vs Wired Jitter Characteristics

The physical medium sets baseline jitter independent of router bufferbloat. CAKE removes router queue buildup, but wireless links still add retransmissions, beacon intervals and airtime contention. Figures below are typical estimates for residential conditions, not lab measurements.

USB Wi-Fi Adapter

Higher Jitter / Not Recommended

USB Wi-Fi adapters communicate over USB endpoints subject to host controller scheduling and USB Selective Suspend power states. Compact antennas lack diversity, so jitter in typical homes is noticeably higher than with PCIe cards or cable.

Mechanical limits:

  • Typical jitter variance: roughly ±15-40 ms (estimate)
  • Subject to USB scheduling and sleep states
  • Compact antenna design limits signal diversity

PCIe Wi-Fi 6E / Wi-Fi 7 Card

Acceptable When Cable Is Impossible

View on Amazon

M.2 Key-E modules (Intel AX210 / BE200) on a PCIe bracket use direct PCIe interrupts and external antennas. In a clean 5 or 6 GHz environment jitter is typically low (a few ms), rising under household airtime contention. Disable adapter power saving and pick a clear channel.

Mechanical limits:

  • Typical jitter: roughly ±2-5 ms on a clean channel (estimate)
  • Direct PCIe interrupt delivery
  • Still vulnerable to airtime contention

Cat5e / Cat6 Patch Cable

Deterministic / Standard Choice

View on Amazon

Switched full-duplex Ethernet eliminates RF interference and collisions, and its transmission jitter is negligible compared to Wi-Fi. Note: a wired connection does not eliminate bufferbloat on an unmanaged router, because queue delay in the router affects wired and wireless packets equally. If you cannot run a cable, powerline or MoCA adapters are worth considering before USB Wi-Fi.

Mechanical limits:

  • Negligible physical transmission jitter
  • Zero RF contention or retransmissions
  • Requires SQM to eliminate router queue delay

* As an Amazon Associate I earn from qualifying purchases.

NIC Driver Tuning: Optional Microsecond-Scale Tweaks

Router SQM fixes millisecond-scale Bufferbloat (30-150 ms). Windows network driver defaults, by contrast, prioritize energy efficiency and CPU offloading, which can add tens to hundreds of microseconds of processing delay. For most players this is far below what you can feel, so treat this section as optional fine-tuning to apply after SQM and only if LatencyMon shows NIC driver spikes. Change one setting at a time and re-measure.

  1. 1Disable Energy Efficient Ethernet (EEE), Green Ethernet and Power-Off Options

    Configuration in Windows:

    1. Open Device Manager → Network adapters → right-click your Ethernet adapter → Properties.

    2. On the Advanced tab, set 'Energy Efficient Ethernet' (EEE) and 'Green Ethernet' to Disabled.

    3. On the Power Management tab, untick 'Allow the computer to turn off this device to save power'.

    • Impact: EEE places the physical layer into Low Power Idle (LPI) during brief gaps; waking from LPI takes roughly 16-30 µs. Negligible for downloads, but unnecessary variance for gaming packet streams.

  2. 2Tune Interrupt Moderation

    Configuration in Windows:

    1. On the Advanced tab, locate 'Interrupt Moderation' or 'Interrupt Moderation Rate'.

    2. Realtek and standard Intel 1GbE adapters (I211/I219-V): Disabled or Off.

    3. 2.5 GbE adapters (Intel I225-V / I226-V, Realtek RTL8125): set to 'Low' or 'Minimal'.

    • Impact: disabling moderation makes the NIC raise an interrupt immediately upon packet reception instead of batching packets in a short coalescing timer (on the order of tens to a couple hundred microseconds).

    • Caution: on 2.5 GbE controllers, fully disabling moderation under heavy throughput can cause high CPU DPC usage. 'Low' keeps the timer short while staying stable.

  3. 3Receive Buffers (Rx Ring Size): Leave Default Unless You Measure

    Configuration in Windows:

    1. On the Advanced tab, locate 'Receive Buffers' (or 'Rx Descriptors').

    2. Defaults are typically 256 or 512. Larger values give headroom during bursts but can also add buffering of their own.

    • Recommendation: leave the default unless LatencyMon or packet-loss counters show a problem, and verify results before and after any change.

In-Game Network Settings: CS2 & Valorant Configuration

Network-related console commands changed substantially with Source 2. The breakdown below separates commands that still work from CS:GO-era commands that were removed or are no longer meant to be set by the player.

CS2 Telemetry & Network Settings

Current in CS2

Active networking commands in Counter-Strike 2:

• rate 786432: maximum acceptable game traffic bandwidth in bytes/sec (exposed in the UI as 'Max Acceptable Game Traffic Bandwidth'; 786432 is the unrestricted default). Leave it at default.

• cl_hud_telemetry_ping_show 2: continuous ping readout (replaces net_graph).

• cl_hud_telemetry_net_misdelivery_show 2: packet loss and out-of-order delivery.

• cl_hud_telemetry_frametime_show 2: frame pacing next to network indicators.

• cl_hud_telemetry_serverrecvmargin_graph_show 1: how early or late your input packets arrive at the server.

• cl_net_buffer_ticks: the user-facing interpolation buffer. cl_interp_ratio is driven by it and should not be set directly. Increase it only if jitter or packet loss persists after fixing your connection, and expect extra latency in exchange for smoother movement.

Essential convars:

  • rate 786432 (default)
  • cl_hud_telemetry_ping_show 2
  • cl_hud_telemetry_net_misdelivery_show 2
  • cl_hud_telemetry_serverrecvmargin_graph_show 1

Legacy CS:GO Commands (Removed or Not Player-Tunable in CS2)

Do Not Copy From Old Guides

CS:GO-era parameters that no longer apply in CS2:

• -tickrate 128: ignored. Official CS2 servers run 64 ticks with sub-tick input.

• cl_interp: read-only in CS2, it reports the effective interpolation amount and is not a value to force.

• cl_interp_ratio: still present, but driven by cl_net_buffer_ticks; do not set it directly.

• cl_updaterate and cl_cmdrate: removed with Source 2; sub-tick replaced the old rate model.

• net_graph 1: removed. Use the cl_hud_telemetry commands instead.

Inactive parameters:

  • -tickrate 128 (ignored)
  • cl_interp (read-only)
  • cl_updaterate / cl_cmdrate (removed)
  • net_graph 1 (removed)

Valorant Diagnostics & Client Buffering

Riot Engine Settings

Network configuration in the Valorant client:

• Settings → Video → Stats: enable 'Network RTT (Avg)' and 'Packet Loss' (Text and Graph) for real-time monitoring.

• Settings → General → Other: 'Network Buffering' (Minimum / Moderate / Maximum). Minimum adds roughly one frame (7.8125 ms) of buffering and keeps the full 128 send rate; Moderate and Maximum add more buffering (about 3 and 5 frames) in exchange for fewer corrections on unstable connections, at the cost of more latency. Keep Minimum on a stable connection and test the others only if you see persistent micro-stutters or packet loss.

• Routing & server latency: in-game ping depends on physical distance and ISP peering to Riot Direct. Waveform tests latency to Waveform's servers, not Riot's; if Waveform shows Grade A but Valorant ping is high, run an mtr trace to diagnose regional ISP routing.

Recommended client options:

  • Network Buffering: Minimum (stable connection)
  • Network RTT: Text & Graph
  • Packet Loss: Text & Graph

Network Tweaks That Do Not Help CS2 & Valorant

Many popular 'ping fix' lists contain tweaks that do nothing for UDP game traffic. Skip these and spend the time on SQM and a wired connection.

TCP-Level Tweaks (Nagle, TCP Optimizer, Registry Edits)

No Effect on UDP Games

Nagle's algorithm, TcpAckFrequency, TCP Optimizer profiles and similar TCP registry tweaks affect TCP connections. CS2 and Valorant gameplay traffic is UDP, so these changes do not touch it. They may only change launcher and download behavior.

Skip:

  • Nagle / TcpAckFrequency edits
  • TCP Optimizer profiles
  • Random netsh tcp tweaks

DNS Changes, MTU Hunting, Disabling IPv6

Placebo for In-Match Latency

DNS is resolved once at connection time and does not affect in-match packets. Default MTU is correct for most connections, and disabling IPv6 does not reduce game latency. The Windows 'reserve 20% bandwidth' QoS myth is also false for normal desktop use.

Skip:

  • Custom DNS for ping reasons
  • MTU experiments without a diagnosed problem
  • Disabling IPv6

Frequently Asked Questions

  • Yes. Average ping is measured on an unstressed line. Bufferbloat is an intermittent queueing event: when your network handles concurrent background data (a stream, a download, or another user), packets wait in hardware queues and individual transit times can jump to 60-150+ ms while the idle average stays low. Run the Waveform test under load to see your loaded latency.

  • The root cause is the same, but the symptoms differ. In CS2, inputs are timestamped client-side and processed in 64-tick frames, so queue delay and jitter make results less predictable and show up as ping spikes and packet delivery anomalies in the telemetry HUD. In Valorant (128 ticks, server-authoritative with client prediction), late or lost packets lead to server corrections that you perceive as rubberbanding or snapping. Riot's Network Buffering setting is designed to trade a little latency for fewer of those corrections.

  • Upstream Bufferbloat occurs in your local router's transmit queue and is fully addressed by router QoS or CAKE SQM. Downstream Bufferbloat occurs in ISP headend buffers, but is mitigated from your router by ingress rate-limiting (shaping download speed slightly below line capacity), which makes senders slow down before ISP buffers fill. To check where delay appears, run an mtr (or PingPlotter) trace to a game server while a speed test runs. Keep in mind that intermediate routers often deprioritize ICMP, so a spike on a middle hop does not always mean real congestion; what matters is whether latency to the final destination rises. If SQM at the correct rates fixes your Waveform grade, the problem was local.

  • Put the ISP device into bridge mode (if the ISP allows it) and connect your own router running SQM or QoS behind it. If bridge mode is not available, some ISP devices can be placed in a 'DMZ/IP passthrough' arrangement so your own router handles NAT and shaping. Without any shaping point you control, you can only reduce background traffic manually.

  • CAKE is a Linux kernel queuing discipline. pfSense and OPNsense are built on FreeBSD, which does not include CAKE; they use FQ-CoDel and FQ-PIE through dummynet/ipfw, which achieves comparable bufferbloat reduction. To run CAKE specifically, you need a Linux-based system such as OpenWrt (on a router or x86 mini PC) or Asuswrt-Merlin on supported hardware. For gigabit throughput with CAKE, use a modern quad-core ARM router (such as the GL.iNet GL-MT6000 Flint 2) or x86 hardware.

  • No. DNS resolves the server hostname once during the initial connection. Once in a match, gameplay packets go directly to an IP address. Alternative DNS providers can speed up domain lookups, but have no impact on in-game latency or jitter.

  • Only in specific routing edge cases. CS2 matchmaking can use Steam Datagram Relay and Valorant uses Riot Direct, both of which already route over dedicated backbones. A third-party gaming VPN adds an extra hop; unless your ISP has badly broken routing to Valve relays or Riot PoPs, it usually adds latency rather than reducing it. A VPN also distorts bufferbloat tests, so disable it when running Waveform.

You May Also Like