How to Spot Bufferbloat on Your Mac Network Connection
Your 500 Mbps connection crawls to a halt the moment someone uploads a photo to iCloud. The culprit has a name: bufferbloat. Here’s how to find it and fix it.
What Is Bufferbloat?
When your network is under load, your router queues outgoing packets in a memory buffer. Under normal conditions, small buffers smooth out tiny traffic bursts. A brief spike of data gets held for a millisecond or two, then forwarded. No harm done.
The problem is that most consumer routers ship with massively oversized buffers that can hold hundreds of milliseconds of data. Think of a highway on-ramp with no metering light: when traffic floods in, cars back up for miles before anyone moves. The on-ramp has plenty of capacity (it can hold hundreds of cars), but that capacity is exactly the problem. Instead of being turned away quickly (and finding an alternate route), every car sits and waits.
The same thing happens in your router. When heavy usage hits (uploading photos, running a Time Machine backup, someone streaming 4K), packets pile up in the buffer waiting for their turn to be transmitted. Latency goes from 20ms to 500ms, 1,000ms, or more. Your packets aren’t lost. They’re just stuck in a queue that should never have been allowed to grow that long.
Eventually the buffer overflows and packets are dropped in bursts, creating simultaneous high latency and packet loss, the worst possible combination for real-time applications like video calls and gaming.
This phenomenon was named “bufferbloat” by Jim Gettys, a Bell Labs engineer, around 2010. It has been a known problem for over a decade, yet most ISP-provided routers still don’t address it. The default configuration on the vast majority of consumer networking equipment is to use large buffers with no intelligent queue management.
The key insight: bufferbloat only appears under load. Your connection seems perfect when idle and falls apart the moment someone starts uploading. A speed test run on a quiet network will show nothing wrong. The problem only reveals itself when the network is actually being used, which is, of course, exactly when you need it to work.
Why Speed Tests Miss It
Speed tests measure your connection in ideal conditions. They saturate your link and measure peak throughput. That’s bandwidth. But they don’t measure what happens to other traffic while the link is saturated, which is exactly the scenario where bufferbloat destroys your experience.
A proper bufferbloat test measures latency during a throughput test, not before or after. The distinction matters enormously.
Think of it this way: checking highway speed at 3 AM doesn’t predict rush-hour congestion. You need to measure travel time while the highway is full. That’s what a bufferbloat test does: it floods your connection with data and then checks how long it takes a small test packet to get through the resulting queue.
Most popular speed tests, such as Ookla’s Speedtest and Fast.com, do report a latency number, but it’s measured before the throughput test begins, when the buffer is empty. This “idle latency” is meaningless for detecting bufferbloat. A connection with 15ms idle latency might jump to 800ms under load. The speed test shows 15ms and calls it good.
What actually matters is latency under load: the latency measured during active data transfer. If your idle latency is 15ms but your loaded latency is 800ms, you have severe bufferbloat. That 785ms difference is the time your packets spend sitting in a bloated buffer, waiting.
This is why people with “fast” internet (500 Mbps, even gigabit) still have terrible experiences during video calls when anyone else on the network is doing anything. The speed is real. The buffering problem is also real. And the speed test doesn’t measure the second thing.
How Bufferbloat Wrecks Your Day
Bufferbloat doesn’t show up in benchmarks. It shows up in your daily life when multiple things happen on your network at once. Here are the most common scenarios:
The common thread: one device doing something bandwidth-heavy makes every other device suffer. On a well-managed network with proper queue management, all four scenarios above should work simultaneously without noticeable degradation. The fact that they don’t is a router configuration problem, not a bandwidth problem.
How to Test for Bufferbloat on macOS
Method 1: Waveform Bufferbloat Test (Browser)
The simplest option. Visit the Waveform bufferbloat test at waveform.com/tools/bufferbloat in Safari or any browser. Cloudflare’s speed test at speed.cloudflare.com also includes a bufferbloat measurement under its “Advanced Metrics” section.
These tests run a speed test while simultaneously measuring latency. The difference between your idle latency and your loaded latency is the bufferbloat penalty.
The Waveform test assigns a bufferbloat grade from A+ to F:
- A+: Latency stays under 5ms above baseline under load. Excellent. Your router has proper queue management.
- A: Latency increases by less than 30ms under load. Very good for all real-time applications.
- B: Latency increases by 30–60ms. Acceptable for most use cases, but you may notice during competitive gaming.
- C: Latency increases by 60–200ms. Video calls will stutter when the network is busy.
- D: Latency increases by 200–400ms. Significant degradation during any concurrent usage.
- F: Latency increases by 400ms+ under load. Severe bufferbloat. Real-time applications are unusable during heavy network activity.
Method 2: Terminal DIY Test
You can demonstrate bufferbloat manually with two Terminal windows. This is more hands-on, but it makes the problem viscerally clear.
Window 1: Start a continuous ping to measure latency in real time:
ping 1.1.1.1
Watch the round-trip times. On a quiet network, you’ll see something like 15–25ms consistently.
Window 2: Saturate your connection with a large download and upload:
# Saturate download
curl -o /dev/null http://speedtest.tele2.net/10GB.zip &
# Saturate upload (runs for 30 seconds)
curl -T /dev/zero http://speedtest.tele2.net/upload.php --max-time 30
Now look back at Window 1. If your ping times jump from ~20ms to 200ms, 500ms, or higher during the transfer, you have bufferbloat. The bigger the jump, the worse the bloat.
Press Ctrl+C in both windows when you’re done. This method is manual and a bit awkward, but it demonstrates the concept in a way that’s impossible to ignore. You can watch the latency climb in real time as the buffer fills.
Method 3: Healthy Network’s Built-in Speed Test
How to Fix Bufferbloat
The Real Fix: Smart Queue Management (SQM)
Bufferbloat is a router problem, not a Mac problem. The fix is at the router level.
SQM (Smart Queue Management) algorithms like fq_codel and CAKE manage the buffer intelligently. Instead of letting the queue grow unchecked, they keep queues short, prioritize small latency-sensitive packets (like VoIP audio), and drop packets early rather than letting them pile up into a massive backlog. The result: latency stays low even under full load. Your Zoom call works while Time Machine backs up in the background.
Which routers support SQM:
- OpenWrt (any compatible router): Best SQM support, most configurable. Install the
sqm-scriptspackage and enable CAKE or fq_codel on your WAN interface. - Ubiquiti EdgeRouter / UniFi Dream Machine: Built-in Smart Queue feature. Enable it under your WAN/Internet settings and set your WAN speed to 80–90% of your measured speed (Ubiquiti provides a “Pre-populate” button to help with this).
- eero (recent firmware): Simplified “Optimize for Conferencing and Gaming” toggle in the eero app. Less configurable, but effective for most users.
- GL.iNet routers: Many models run OpenWrt and support SQM out of the box via their admin panel. Good balance of ease-of-use and configurability.
- Some ASUS routers with Merlin firmware: The Asuswrt-Merlin third-party firmware adds fq_codel support on many ASUS models.
ISP-provided routers almost never support SQM. If you’re renting a router from your ISP, this alone is a compelling reason to buy your own. A $60 router running OpenWrt with SQM enabled will outperform your ISP’s $200 “premium” gateway in every real-world scenario where latency matters. If you suspect your ISP is also throttling your connection on top of bufferbloat, the combination can make real-time applications unusable.
Quick Fixes on macOS (When You Can’t Change the Router)
If you can’t replace or reconfigure your router, you can reduce the impact of bufferbloat from the Mac side:
- Pause heavy uploads before important calls. Go to System Settings → Apple ID → iCloud and pause sync. This prevents iCloud Photo Library and iCloud Drive from saturating your upload bandwidth during a meeting.
- Identify upload-heavy processes. Open Activity Monitor (Applications → Utilities → Activity Monitor), click the Network tab, and sort by “Sent Bytes.” This reveals which app is flooding your upload link. Note that Activity Monitor shows throughput but not connection quality. See our Healthy Network vs. Activity Monitor comparison for why both tools serve different purposes.
- Reduce Time Machine backup frequency. Go to System Settings → General → Time Machine → Options and change backup frequency from “Automatically” (hourly) to “Daily” or “Manually.” For more control over backup timing, third-party tools like TimeMachineEditor let you schedule specific hours.
- Protect your upload bandwidth first. If your connection is asymmetric (e.g., 200 Mbps down / 10 Mbps up), the upload side bloats first because it has far less headroom. Controlling upload-heavy apps has the biggest impact on bufferbloat symptoms.
The Nuclear Option: Rate-Limit Your Connection
If you can’t replace your router and can’t enable SQM, there’s a blunt but effective workaround: reduce your configured WAN speed to 85–90% of your actual speed.
Most routers let you manually set your WAN upload and download speeds (often under QoS or bandwidth settings). By telling the router your connection is slightly slower than it actually is, you create artificial headroom. The router’s traffic shaper (even a basic one) will start throttling before the ISP’s buffer fills, keeping the queue short.
This sacrifices roughly 10–15% of your peak throughput for dramatically better latency under load. If you have a 100 Mbps connection and cap it at 85 Mbps, your top speed drops by 15 Mbps, but your latency during heavy usage might drop from 800ms to 30ms. For most people, that is an overwhelmingly worthwhile trade.
Monitoring Over Time
A single bufferbloat test tells you your current state, but network conditions change constantly. ISP congestion varies by time of day. New devices join your network. Firmware updates alter router behavior. A backup schedule you forgot about kicks in every afternoon.
Continuous monitoring reveals patterns that a one-time test can’t. “My latency spikes to 400ms every day at 3 PM” might coincide with an automated Time Machine backup, a family member’s streaming schedule, or ISP congestion in your neighborhood. Without ongoing data, you’re guessing at the cause.
After enabling SQM or making router changes, continuous monitoring also serves as validation. You can confirm that your fix actually works under real-world conditions, not just during a brief test, but across days and weeks of normal usage.
The diagnostic report feature in Healthy Network can capture these patterns over time and compile them into a shareable report. This is particularly useful when calling your ISP: instead of saying “my internet feels slow sometimes,” you can say “my latency under load averages 600ms between 7 and 10 PM, here’s the data from the past two weeks.” That’s a conversation ISP support can actually act on.
Frequently Asked Questions
Can bufferbloat happen on fiber?
Yes. Bufferbloat is a router buffering problem, not an ISP speed problem. Even a 1 Gbps fiber connection will bloat if your router has oversized buffers and no SQM. Fiber typically has lower baseline latency, so the relative increase is even more dramatic, going from 3ms idle to 500ms loaded.
Does upgrading my internet plan fix bufferbloat?
No. A faster plan actually makes bufferbloat worse, because the router can fill its buffer faster. Going from 100 Mbps to 1 Gbps without SQM means the buffer fills 10x faster, creating more sudden latency spikes. Speed doesn’t fix queuing; queue management does.
What’s a good bufferbloat grade?
A+ means latency increases by less than 5ms under load. Excellent. A is under 30ms, still very good. B (30–60ms) is acceptable for most use cases. C and below means you’ll notice problems during video calls when the network is busy. D and F require immediate attention if you depend on real-time applications.
Is bufferbloat the same as packet loss?
They’re related but different. Bufferbloat causes high latency because packets wait in an oversized queue. Packet loss happens when the queue finally overflows and packets are dropped. Bufferbloat often leads to packet loss, but not always. Sometimes you get 800ms latency with 0% loss, which is still terrible for real-time applications.
Test for bufferbloat in one click
Healthy Network’s built-in speed test measures latency under load and gives you a bufferbloat grade. No Terminal juggling required.
Download for Mac