DIAGNOSTIC TOOLKIT
Bufferbloat Test: Measure Latency Under Load
LumaProbe measures response time before a transfer, while downloading and while uploading. The comparison can reveal queueing delay that affects calls, games and remote work even when headline speed is high.
How this check works
The test first records ten small HTTPS round trips while no deliberate bulk transfer is running. It uses the median successful sample as idle latency. It then downloads three data blocks in parallel while continuing to send small requests, and repeats the same concurrent sampling during a six-mebibyte upload. The two loaded medians are compared separately with idle latency.
LumaProbe assigns an explanatory responsiveness grade from the larger increase: A for no more than 15 milliseconds, B for no more than 30, C for no more than 60, D for no more than 100 and E above 100. The thresholds are published so the grade can be understood; it is not an industry certification or a promise about every application.
Prepare for a useful result
Start with avoidable background transfers paused so the first run describes the connection under the test’s controlled load. Label Wi-Fi, Ethernet or mobile correctly and use the same device for comparisons. If possible, add an Ethernet run so a wireless queue can be separated from the broadband or router queue.
Then repeat during the ordinary situation that causes trouble—for example while another household device backs up or downloads a game. Do not deliberately saturate a metered mobile connection without checking the data allowance. A full run transfers roughly twenty-four mebibytes plus small request overhead.
What the result can tell you
A small increase means the route stayed relatively responsive while the deliberate transfer was active. A large download-loaded increase can affect calls and games when someone receives a large file; a large upload-loaded increase can appear during cloud backups, camera uploads or file sharing. Upload queueing is easily missed by tests that measure only download load.
The result helps identify a condition rather than a component. Queueing can occur in the device, Wi-Fi access point, router, modem, provider access network or another point on the route. A repeatable Ethernet result across several runs is stronger evidence than a single Wi-Fi grade.
Limits of this browser test
This is a short HTTPS browser test against one United Kingdom node. Browser scheduling, server distance, VPNs, security software and a very fast connection can change the sample count and measured rates. It does not inspect router queues, identify a particular queue-management algorithm or emulate every type of real-time traffic.
A good grade does not prove that a game server or video platform is healthy. A poor grade does not prove provider fault, especially on Wi-Fi. Compare controlled runs, retain the actual idle and loaded numbers and use application-specific latency where available.
What to do next
If the rise appears only on Wi-Fi, improve placement, interference or wireless backhaul before changing the broadband package. If it remains over Ethernet, check whether the router offers documented Smart Queue Management, SQM, CAKE, FQ-CoDel or an equivalent queue-control feature. Save the original configuration before changing anything.
Queue management often requires a configured rate below the real line capacity and can reduce maximum benchmark speed in exchange for responsiveness. Avoid copying unexplained settings from forums. If the router cannot manage the connection rate, seek model-specific guidance or provider support before purchasing replacement hardware.
Read the complete LumaProbe test methodology and privacy notes →