Interface Queue Calculator
Assess txqueuelen sizing against bandwidth-delay product and estimate drop risk.
Inputs
Optimal txqueuelen (packets, BDP/MTU)
1,667
Current Sizing Assessment
Well-sized
Queue Overrun Risk?
true
Excess Rate Beyond Drain Capacity (pps)
6,666.7
Time to Fill Queue at Excess Rate (ms)
150.00
Step by step
Values used
Configured txqueuelen (packets) = 1,000; Interface Bandwidth (Mbps) = 1,000; Round-Trip Time (ms) = 20; Avg Packet Size (bytes) = 1,500; Incoming Packet Rate (pps) = 90,000
Optimal queue depth
optimal_queue_packets = BDP / avg_packet_size
Optimal txqueuelen (packets, BDP/MTU)
= 1,667
Current Sizing Assessment
= Well-sized
Queue Overrun Risk?
= Yes
Excess Rate Beyond Drain Capacity (pps)
= 6,666.7
Time to Fill Queue at Excess Rate (ms)
= 150.00
How it works
The txqueuelen parameter sets how many packets the kernel can buffer for a network interface before the queueing discipline (qdisc) starts dropping new arrivals, and correctly sizing it means balancing two failure modes: too small drops packets during legitimate bursts or high-latency paths, while too large introduces bufferbloat — packets sit queued for so long that added latency hurts interactive and real-time traffic even though nothing is technically dropped. A reasonable target ties queue depth to the bandwidth-delay product divided by average packet size, giving just enough buffer to absorb one RTT's worth of in-flight data.
Formula
Optimal queue depth
optimal_queue_packets = BDP / avg_packet_size
- BDP
- bandwidth-delay product in bytes
- L_{pkt}
- average packet size in bytes
Frequently Asked Questions
How do I check and change txqueuelen?
`ip link show <iface>` displays the current qlen value; change it with `ip link set <iface> txqueuelen <N>` (temporary, resets on reboot unless persisted via a network manager profile or udev rule).
What is bufferbloat and how does it relate to txqueuelen?
Bufferbloat is excessive queuing delay caused by oversized buffers that let packets sit queued far longer than necessary before being dropped or transmitted, defeating TCP's congestion control feedback loop — modern fixes like fq_codel and CAKE actively manage queue depth and latency rather than relying purely on a large static txqueuelen.
Does a higher-bandwidth interface always need a larger txqueuelen?
Not necessarily on its own — queue sizing should scale with bandwidth-delay product (which factors in RTT, not just bandwidth), so a high-bandwidth but low-latency LAN link may need a smaller queue than a lower-bandwidth but high-latency WAN link.