Your video calls freeze on upload — the number your speed test hides

Your internet "feels fast." Download tests glow green. And yet, twice a week, your video call turns into a wax museum the moment a cloud backup, sync client, or large email attachment starts moving.

Here's the thing almost everyone misses: a video call is an upload-heavy application. Your camera stream has to travel out. Download speed — the number every ISP advertises and every speed test leads with — is nearly irrelevant to how you look and sound to the other side.

What actually kills the call

1. Upload saturation. Most home plans are asymmetric — 500 Mbps down, 20 up. Your call needs ~3 Mbps of steady upload. The moment OneDrive decides to sync 10 GB, that 20 Mbps pipe is full, and your face is queued behind it.
2. Bufferbloat. When the upload pipe saturates, latency on the whole connection climbs — often from 10 ms to 300+ ms. That's why your screen share stutters even though "nothing else is happening."
3. Jitter on the upstream. Wi-Fi retransmissions plus a competing upload means your packets arrive in bursts. Codecs hate bursts more than they hate delay.

The 25-second diagnosis

Run a test that measures latency per direction while the line is saturated — not just idle ping. SpeedPulse (free, no signup, no app, no cookies, all client-side — full disclosure: I built it) does exactly this:

• it keeps a ping train running during both the download and upload phases, then reports loaded − idle latency for each direction separately
• grades the worse direction A+ to F on the community bufferbloat scale
• measures jitter (mean absolute difference between consecutive pings)
• translates results into plain-English verdicts — one of them is specifically for video calls
• cross-checks 8 independent CDN edges afterward, so you can see if your ISP flatters the speed-test server itself

If your download direction grades A but upload grades C or worse — congratulations, you found exactly why your camera freezes during backups.

The fixes

1. Cap your upload ~10–20% below your plan rate in your router's QoS/SQM settings. On OpenWrt, SQM with cake does this in two minutes. The backup still finishes (it just takes 10% longer), and your calls stop dying.
2. Schedule sync-heavy apps (Backblaze, iCloud, Google Drive) outside meeting hours, or throttle them in their own settings.
3. Wire the workstation. One less source of upstream jitter you can't control.
4. If you can only fix one direction, fix upload. It's the thin end of every asymmetric connection.

The counter-intuitive part: making your internet slightly slower on purpose is what makes calls feel instant. Queue discipline beats raw bandwidth for real-time apps — every time.

Why most speed tests won't show you this

Idle ping and download throughput are easy; loaded upload latency requires saturating your upstream while pinging through it, per direction, without ICMP. In a browser you time HTTPS round trips with fetch(url, { mode: 'no-cors' }) and performance.now() — opaque responses, but full network round trips, which is all timing needs. If you're curious about the exact methodology (and the limitations we're honest about): How SpeedPulse measures jitter, bufferbloat and 8 CDN latencies.

---

More background if you want it: how much internet speed video calls actually need · what bufferbloat is.

Run the test before your next meeting and check the upload direction grade — drop it in the comments if it surprises you: speedpulse.tech