Measuring bufferbloat on my own line
I have spent about seven years in competitive FPS, which means I have spent about seven years developing opinions about lag that I could not defend. The specific complaint was always the same: someone in the house starts a download, and the game feels wrong. Not slow — wrong. Inputs land late in a way that a frame counter does not show.
The usual explanations are unsatisfying. The connection is not saturated from the game’s point of view; a competitive shooter uses a rounding error of the available bandwidth. Speed tests come back fine. So I measured it.
The baseline
The probe is a TCP connect to 1.1.1.1:443, sampled continuously, in three phases of forty
seconds: idle, saturated download, saturated upload.
| Phase | Throughput | p50 | p95 | p99 | max |
|---|---|---|---|---|---|
| Idle | — | 15.55 ms | 31.04 ms | 34.44 ms | 47.2 ms |
| Download | 457.4 Mbps | 34.47 ms | 530.56 ms | 1038.82 ms | 1045.39 ms |
| Upload | 41.7 Mbps | 11.31 ms | 30.63 ms | 31.29 ms | 31.93 ms |
Two things jump out.
The first is that the median is a liar. Under a saturating download the median round trip goes from 15.55 ms to 34.47 ms. That is a 19 ms increase, and if you were watching a dashboard showing average or median latency you would conclude the link was healthy under load. Meanwhile the 99th percentile went up by 1,004 ms. One packet in a hundred is arriving a full second late. In a game running a 64 Hz tick, a second is sixty-four ticks — the entire round is over before that packet matters.
The second is that the upload path does not do this at all. Under a saturating upload, p99 is 31.29 ms — actually lower than the idle p99 of 34.44 ms, within noise. Whatever is absorbing my download traffic has no equivalent on the way out. That asymmetry is the clue that this is a queue somewhere specific, not a general property of the link.
Finding the queue
A single end-to-end number tells you a queue exists but not where it is. So the second run probes each hop on the path independently, idle and then under a 448 Mbps download.
| Hop | Idle p50 | Loaded p50 |
|---|---|---|
| 1 · router (LAN) | 1 ms | 1 ms |
| 3 · ISP edge | 11 ms | 77 ms |
| 9 · ISP core | 13 ms | 109 ms |
| 12 · internet | 14 ms | 111 ms |
There it is. My own router does not move. One millisecond idle, one millisecond under a load that is filling the link. Whatever is queuing, it is not the hardware on my desk, and no amount of QoS configuration on my side would have found it.
The very next hop goes from 11 ms to 77 ms, and everything beyond it inherits that delay and adds a little. The queue is one hop out, in the carrier’s access equipment, and it is deep enough to hold roughly a second of my traffic before it drops anything.
Hop 2 never answered in either run. I have left it out of the table rather than estimating it; an unanswered hop is a gap in the measurement, not a zero.
It drops packets too
A third run measured loss rather than delay under the same saturation: of 17 answerable echo requests, 2 went unanswered — 11.8% loss, with a p99 of 1,173 ms on what did come back.
This is the part that connects back to the felt experience. Bufferbloat is usually described as a latency problem, and it is, but a buffer that deep also means that when it finally overflows, it overflows in bursts. Delay plus burst loss is exactly the input pattern that makes a game feel unpredictable rather than merely laggy.
What this actually is
This is textbook bufferbloat: an oversized buffer, no active queue management, and a TCP sender happily filling it because filling buffers is what TCP is designed to do. The buffer is doing what it was built for. It was just built too big, and nothing is managing it.
The fix is not more bandwidth. More bandwidth fills the same buffer faster. The fix is an AQM — fq_codel or CAKE — applied where the queue actually forms. Since the queue here is on the carrier’s side of my demarcation point, what I can do locally is shape my own egress to sit just under the bottleneck rate so the carrier’s buffer never gets the chance to fill. That is the next measurement.
The thing I actually learned
I could feel this for seven years before I could measure it, and the measurement took an afternoon. The gap between those two facts is most of what separates a player complaining about lag from an engineer who can point at the hop.
All figures above come from three capture runs on 1 September 2026 against my own residential connection. The three raw captures behind it are summarised in the latency lab writeup; nothing here is estimated or reconstructed.