Loaded latency and bufferbloat explained

Why fast connections can still feel slow

Routers and network equipment buffer packets to absorb short bursts. Some buffering is useful, but a long queue can hold interactive traffic behind a large download or upload. The speed test may still show high throughput while a call becomes delayed, a game responds late or web pages pause. This undesirable delay under load is commonly called bufferbloat.

The symptom often appears only when the connection is busy. An idle ping can look excellent, then rise sharply when someone starts a backup or game download. That is why download speed and idle latency alone do not describe the complete experience.

How LumaProbe measures loaded latency

LumaProbe first sends ten small HTTPS requests without the deliberate bulk transfer and displays the median successful time as idle latency. During the parallel download phase it sends more small HTTPS requests and displays their median as loaded latency. The increase between the two is the most useful comparison on the same route.

This is browser-observed HTTPS timing, not raw ICMP or the full Realtime Response Under Load laboratory method. Browser scheduling and server processing add overhead. A very fast transfer may finish before many loaded samples are collected, while a distant server raises the base value. Repeatability matters more than one threshold.

Read the increase, not only the absolute number

Suppose idle latency is 25 ms and loaded latency is 35 ms: the route stayed fairly responsive during this short download. If idle latency is 25 ms and loaded latency repeatedly rises to 180 ms, traffic is spending much longer waiting when the path is busy. The exact acceptable increase depends on the application and route, but interactive uses notice large changes.

A high idle value and a small loaded increase can instead reflect server distance or a consistently slow route. A low idle value with a large increase points more directly towards queueing during saturation. Compare beside the router, over Ethernet and with other household traffic paused to locate where the increase begins.

Upload saturation can be the hidden cause

Upstream capacity is often much lower than downstream capacity. A cloud backup or camera upload can fill it, delay acknowledgements and make downloads or calls behave poorly. LumaProbe measures loaded latency during its download phase, so it does not reproduce every upstream queueing scenario. You can compare responsiveness while a known upload runs, but avoid disrupting other users or exceeding a metered allowance.

If the problem coincides with backups, schedule or rate-limit them using supported application settings. Confirm the change with the same test conditions. Removing one competing upload is a reversible diagnostic step; buying a faster package before proving upload saturation is not.

Where queue management fits

Modern queue-management algorithms try to keep queues short and share capacity more sensibly. Some routers expose Smart Queue Management, SQM, or quality-of-service controls. These features may reduce maximum benchmark throughput slightly because they need an accurate ceiling below the actual link rate, but the trade can improve responsiveness under load.

Do not copy unknown settings blindly. Provider hubs may hide these controls or require their own traffic policies. Record the original configuration, use manufacturer documentation and change one setting at a time. A router cannot manage congestion that occurs farther inside the provider network, although shaping just below the access rate can sometimes keep the active queue local.

A practical diagnosis sequence

First repeat the test with other transfers paused. Then compare Wi-Fi with Ethernet and test beside the router. If the loaded increase appears only on distant Wi-Fi, investigate wireless contention or backhaul. If it remains on Ethernet across capable devices, check for upload activity, router queue controls and the provider route.

Retest at quiet and busy times and keep local history labels. Contact the provider when high loaded delay or failures persist across devices and Ethernet, especially when accompanied by poor throughput or line symptoms. Describe the measurements as browser evidence from the device-to-server path, not proof of a particular piece of equipment.

Recommended next checks

Compare results beside the router, in the problem location and over Ethernet where possible. Repeat under the same conditions rather than relying on one run. LumaProbe’s browser measurements describe the complete path to its server, so use them to narrow the fault—not as a substitute for a provider line diagnostic.

More help

Browse all internet and Wi-Fi guides, read how LumaProbe tests connections, or report a correction through LumaContact.