What is Queue Depth?
Updated: 3 days ago
Queue depth is the amount of data waiting in a network queue before it can be transmitted or processed. It can be measured in packets or bytes. Queue depth matters because a persistent backlog adds queuing delay, and once a queue fills it can also lead to packet loss or congestion signalling. The important distinction is that a deep queue is not automatically useful capacity: it is traffic waiting for a bottleneck to become available.
What does queue depth mean?
Routers, switches, WiFi interfaces, operating systems and network adapters use buffers to absorb short differences between the rate packets arrive and the rate they can leave. A queue is the ordered set of packets waiting in that buffer. Queue depth describes how much is currently waiting.
The IETF's AQM characterisation guidance defines buffer occupancy as the amount of data in a queue, measured in bytes or packets, and distinguishes this from maximum buffer size. RFC 7928 also explains that end to end delay includes queuing delay alongside propagation, serialization, service and medium access delay.
Queue depth or buffer occupancy: how much data is waiting now.
Maximum buffer size: the most data the buffer can hold.
Queueing delay: how long packets spend waiting.
Sojourn time: the time an individual packet spends in the queue.
Packet loss: what can happen when a queue has no room for newly arriving traffic.
Queue depth is not the same as bandwidth
Bandwidth describes capacity. Queue depth describes waiting traffic. A high capacity link can still develop a queue if packets arrive faster than that link can transmit them, even temporarily. Conversely, a slower link can have a shallow queue when demand remains below its available capacity.
If you need the capacity concept first, see What is Bandwidth?. For the rate actually transported over time, see What is Sustained Throughput?.
How queue depth turns into latency
Queue depth becomes especially useful when it is related to the rate of the bottleneck. The same number of queued bytes produces very different waiting time on a 100 Mbps link and a 1 Gbps link.
Techie Broadband calculation: 1 MB queue
Assume 1 MB means 1,000,000 bytes, or 8,000,000 bits, and ignore additional scheduling effects. Approximate serialization time for the queued data is queued bits divided by bottleneck bit rate.
At 20 Mbps: 8 Mb ÷ 20 Mbps = 0.40 seconds, approximately 400 ms.
At 100 Mbps: 8 Mb ÷ 100 Mbps = 0.08 seconds, approximately 80 ms.
At 500 Mbps: 8 Mb ÷ 500 Mbps = 0.016 seconds, approximately 16 ms.
At 1 Gbps: 8 Mb ÷ 1,000 Mbps = 0.008 seconds, approximately 8 ms.
These are theoretical Techie Broadband calculations showing serialization time for data already ahead in the queue. They are not predictions of total internet latency. Real RTT also includes propagation, processing, access technology, scheduling and queues elsewhere on the path.
Why queues exist
A zero length queue at every instant is not the goal. Packet traffic is naturally bursty. Buffers can absorb short term mismatches between arrival and departure rates so that a brief burst does not immediately become packet loss.
The IETF's active queue management recommendations in RFC 7567 explain that buffers should be able to accommodate normal traffic bursts while AQM can keep average queue size small enough to preserve room for those bursts.
When queue depth becomes a problem
The problem is usually a queue that remains deep rather than one that briefly grows and drains. A standing queue means packets repeatedly encounter a backlog at the same bottleneck. That can increase loaded latency even when throughput still looks healthy.
This is closely related to bufferbloat. RFC 8289 describes CoDel and explains why persistent excess delay is more useful to control than queue length alone, particularly where link rates can vary, such as WiFi.
A connection can therefore deliver high Goodput while still feeling poor for interactive traffic if deep queues make RTT rise sharply under load.
Queue depth, congestion and packet loss
A queue normally builds because traffic is arriving at a resource faster than it can currently serve it. If that mismatch persists, occupancy grows. If no queue management intervenes and the queue reaches its limit, further packets may be dropped.
That relationship makes queue depth closely connected to network congestion, but they are not identical. Congestion is the demand and capacity condition. Queue depth is one observable consequence at a particular queue.
Modern queue management can signal congestion before a buffer becomes completely full. RFC 9331 describes how active queue management and ECN can provide congestion signals while keeping queues shallow in low latency architectures.
Where queues can form on a broadband connection
There is not one universal broadband queue. Packets can wait at several points from an application to a remote service. The queue that matters at a particular moment is usually associated with a resource whose service rate is below the traffic offered to it.
Application or operating system: data can wait before transmission.
Home router: traffic can queue before the WAN link, particularly during uploads.
WiFi: contention and changing radio rates can alter how quickly queued frames are served.
Ethernet interface: a faster upstream interface feeding a slower link can create a queue.
ONT, modem or access equipment: implementation and access scheduling can introduce buffering.
Access and ISP networks: aggregation or other constrained resources can queue traffic.
Interconnection and remote networks: congestion can occur beyond your ISP.
Remote server: the destination itself can have processing or network queues.
Why upload queues are particularly noticeable
Many UK broadband products have less upload capacity than download capacity. On an asymmetric service, a large cloud backup or file upload can therefore reach the upstream bottleneck more easily than ordinary downstream activity reaches the download limit.
When the upstream queue becomes persistent, acknowledgements and latency sensitive traffic can wait behind bulk traffic. This is why a connection can have apparently adequate upload speed yet show much higher latency while the upload is saturated.
Queue depth on WiFi is more complicated
WiFi is a shared radio medium whose usable transmission rate can change with signal quality, interference, contention, retransmissions and modulation. A queue measured in packets or bytes therefore does not map to one fixed delay.
This is one reason RFC 8289 emphasises packet sojourn time rather than queue length alone for CoDel. If the service rate changes, the delay represented by the same byte depth changes too.
FIFO, tail drop and active queue management
FIFO and tail drop
A simple first in, first out queue serves packets in arrival order. With tail drop, new packets are discarded when the queue is full. This is simple, but a persistently full queue can add substantial delay before loss finally signals congestion.
Active Queue Management
AQM attempts to manage congestion before a queue simply remains full. RFC 7567 recommends active queue management as a way to control average queue size, reduce delay and preserve capacity for natural bursts.
CoDel
Controlled Delay, or CoDel, focuses on the time packets spend in a queue. RFC 8289 describes it as a framework for controlling excess delay caused by bufferbloat.
FQ-CoDel
FQ-CoDel combines flow queueing with CoDel. RFC 8290 describes the scheduler and AQM combination as a way to reduce latency and lessen the impact of head of line blocking from bursty traffic.
How to diagnose excessive queueing on home broadband
Use wired Ethernet where practical so WiFi is not the first unknown.
Check the negotiated Ethernet rate on the test device and router.
Measure idle Round Trip Time before creating heavy traffic.
Run a sustained download and observe latency at the same time.
Repeat with a sustained upload, which is often the easier bottleneck to saturate on asymmetric services.
Pause cloud backups, game downloads, sync clients and other competing traffic, then retest.
Test more than one destination so a single remote server is not mistaken for a local queueing problem.
Compare results at different times to separate persistent local behaviour from wider peak time effects.
If the router exposes queue statistics, inspect occupancy, drops and the configured queue discipline.
Where appropriate, test Smart Queue Management or an AQM capable router configuration and compare loaded latency.
For the latency measurement itself, see What is Round Trip Time (RTT)?. To understand why performance can change during busy periods, see What is Peak Time Performance?.
What queue depth does not tell you
Queue depth is not a complete performance metric on its own. A count of 100 packets does not reveal packet sizes, service rate, scheduler behaviour or how long those packets have been waiting. A byte count is better for some calculations, but it still needs the departure rate to translate occupancy into time.
For real troubleshooting, combine queue information with RTT, loaded latency, throughput, loss and the location of the suspected bottleneck. This avoids treating a large buffer as automatically bad or a small queue as automatically good.
Queue depth and faster broadband
Faster access speeds can reduce the serialization time represented by a given number of queued bytes, but they do not eliminate queueing. On multi gigabit broadband, bottlenecks can move to the router, Ethernet adapter, switch, WiFi link, VPN processing, device or remote service.
A download speed test that reaches the expected rate therefore does not prove loaded latency is low. Capacity and responsiveness need to be measured separately.
Frequently asked questions about queue depth
Is a high queue depth always bad?
No. A temporary queue can absorb normal traffic bursts. Persistent depth that creates significant delay is more concerning than a short queue that drains quickly.
Is queue depth measured in packets or bytes?
It can be measured in either. RFC 7928 describes buffer occupancy in bytes or packets. Bytes are useful when relating occupancy to a link rate, while packet counts can be useful for implementation and packet scheduling analysis.
Does a larger router buffer make broadband faster?
Not inherently. More buffer capacity can absorb bursts, but an unmanaged large buffer can allow a standing queue to grow and increase latency. The underlying bottleneck capacity has not increased.
Is queue depth the same as bufferbloat?
No. Queue depth is an occupancy measurement. Bufferbloat describes excessive buffering that produces unnecessary delay. A queue can have depth without being bloated.
Can queue depth affect gaming and video calls?
Yes, when a persistent queue increases delay or jitter. Interactive applications care about timely packet delivery, not only the maximum throughput of the broadband connection.
Can I see queue depth in a normal speed test?
Usually not directly. A speed test may reveal the effect through increased latency under load, but the actual queue occupancy may only be visible through router, operating system or network equipment telemetry.
Key takeaway
Queue depth tells you how much traffic is waiting at a network queue. It is useful because waiting traffic can become queuing delay, but depth must be interpreted alongside the bottleneck rate and the time packets spend waiting. Healthy networks need enough buffering for normal bursts without allowing persistent queues to dominate latency. For broadband troubleshooting, the practical question is not simply how big the buffer is, but whether a standing queue forms under load and how much delay it adds.
To explore the related technical concepts used in this Queue Depth guide, visit our broadband terminology guide.
