When a game stream stutters as someone starts a download, test latency at idle and under load. The difference can reveal queueing delay, often called bufferbloat. It cannot prove the router is at fault by itself: Wi-Fi, a modem, the ISP link, or another bottleneck may be responsible.
Quick verdict
A Bufferbloat test for game streaming measures latency before and during download and upload activity. Run it first over Ethernet, then over your normal Wi-Fi, and repeat when the lag usually happens. A consistent rise under load points to queueing somewhere on the path. It does not identify the router, modem, Wi-Fi, or ISP without further comparisons.
For cloud gaming, inspect download-loaded latency; for Twitch or YouTube Live, inspect upload-loaded latency too. Test both if the household is downloading and broadcasting at the same time.
What a bufferbloat test measures
Bufferbloat is excessive delay caused when network equipment holds packets in a queue for too long. High throughput and low idle ping do not guarantee a responsive connection when the link is busy. Bufferbloat.net describes the issue as undesirable latency from equipment buffering too much data, while OpenWrt notes the impact on real-time tasks such as gaming and calls.
A browser-based test usually establishes a quiet latency baseline, adds download traffic, adds upload traffic, and measures latency in each loaded phase. Waveform’s Bufferbloat Test explains that its grade reflects added latency under load, not download speed or unloaded ping. Treat its letter grade as a useful signal from that test and endpoint, not a universal guarantee for every game, route, or time of day.
Streaming adds a real-world reason to measure both directions: a cloud game receives video downstream, while a live broadcast sends encoded video upstream. A speed-only test can miss the delay that appears only while another device fills the connection.
A repeatable game-streaming test
Compare like with like so that you can isolate variables instead of guessing.
- Pause avoidable traffic. Stop game downloads, cloud backups, OS updates, and other speed tests. Note any household activity that remains.
- Test by Ethernet first. Connect the gaming device to the router by cable if practical. This reduces Wi-Fi as a variable. Keep your normal VPN state consistent and record it.
- Run a quiet test. Record unloaded latency, latency during download load, latency during upload load, throughput, time, device, and connection type.
- Repeat under the problem load. Test while a large download or upload is active. Do not run multiple test sites at once; they compete for the same link.
- Compare Wi-Fi separately. Repeat on the same device, in the same room, over your normal Wi-Fi. If wired is stable but Wi-Fi is not, investigate signal, interference, distance, and access-point placement first.
- Repeat at different times. Run several comparable tests at quiet and peak hours. A recurring pattern matters more than one spike.
Record the game or streaming service and the target region when known. A nearby generic test server may use a different route from your actual cloud gaming region. See the 9GG CLOUD Network Readiness Test guide for route-aware measurement context.
How to read the result
Compare each loaded latency reading with the idle baseline. A repeatable increase during downloads suggests downstream queueing; a rise during uploads suggests upstream queueing. If both rise, the bottleneck may be shared or more than one link may be saturated.
Separate baseline latency from latency added under load. A high baseline can reflect distance or routing even when queues are controlled. A low baseline can still jump when traffic fills a queue. SQM can manage queueing; it cannot shorten the route to a distant server.
The bottleneck may be Wi-Fi airtime, the router’s WAN queue, a modem or ONT, a saturated uplink, or congestion farther along the ISP path. Ethernet-versus-Wi-Fi results help isolate the local wireless segment, but do not prove where the remaining delay originates.
How to reduce router queueing
Look for SQM, CAKE, or FQ-CoDel
Check the router’s settings and documentation for Smart Queue Management (SQM), CAKE, or FQ-CoDel. OpenWrt describes SQM as a combination of traffic shaping, flow scheduling, and active queue management. Its documentation also notes that SQM uses router CPU, so a low-powered device may not sustain the full speed of a very fast connection.
On OpenWrt, select the WAN-facing interface and use sustainable upload and download rates measured on your connection. OpenWrt examples start below measured capacity; around 90% can be a tuning starting point, not a universal setting. Too high and traffic can still queue upstream; too low and you sacrifice unnecessary throughput. Follow the OpenWrt SQM setup guide for the exact controls and link-layer options supported by your setup.
Tune one direction at a time
If upload load creates the larger delay, lower the upload shaper slightly, save, and repeat the same test. Tune download separately if needed. Change one value per round and record the old value, new value, throughput, and loaded latency so you can undo a change that costs too much capacity.
Verify QoS instead of trusting its label
A router’s “gaming mode” may prioritize selected traffic, but product labels and classification rules vary. Prioritization cannot create extra line capacity, and it may not control the queue that is filling. Judge it by retesting and by playing under the same competing traffic.
If wired tests remain poor after reasonable SQM tuning, check for double routing between an ISP gateway and a second router, review firmware updates using the manufacturer’s process, and compare results at different times. If the local path tests clean while a particular route remains slow, save timestamps and results for your ISP. For adjacent symptoms, see How to diagnose high network jitter.
Cloud gaming and live broadcasting stress different directions
Cloud gaming sends controller input upstream and receives rendered video downstream, so a large household download can compete with incoming frames. Live broadcasting sends video upstream, so backups and other uploads may fill the upload queue. Streaming a local PC to someone elsewhere depends on the host’s upload path and the remote client’s download path.
Match the test to the symptom. If cloud gameplay becomes delayed during a download, inspect download-loaded latency. If an outbound broadcast stutters while another device uploads, inspect upload-loaded latency. Test each direction alone, then repeat with the combined workload you actually use.
Do not lower stream quality before checking whether the cause is a loaded queue, unstable Wi-Fi, a distant route, or an encoder/device limit. The cloud gaming speed and network guide explains how throughput fits alongside latency, jitter, and packet loss.
Retest and document the change
- Keep the same device, test endpoint, room, and approximate time for before-and-after runs.
- Compare wired with Wi-Fi instead of assuming the router is responsible.
- Record idle latency, download-loaded latency, upload-loaded latency, throughput, and active household traffic.
- Use the same real game, cloud region, or broadcast workload when checking the result in practice.
- Stop tuning when loaded latency is consistently controlled and capacity remains adequate for the household.
This is a documentation-based guide, not a new 9GG CLOUD router benchmark; no specific router, ISP, or before-and-after score was tested for this article. Explore the 9GG CLOUD Tools and Network Lab for further measurement resources.
