Why PingKit Uses 6 Parallel Connections for Speed Tests

Published June 8, 2026 · 7 min read

You're paying for a fast plan. You run a quick test, and the number comes back well below what your bill promises. Before you call your provider, it's worth understanding how the measurement actually works — because the way a speed test moves data has a huge effect on the result. At PingKit, our speed test deliberately uses several connections at once, and this post explains why that design choice gives you a more honest picture of your line.

The Problem With a Single Connection

When your device downloads a file, it typically does so over TCP, the protocol that quietly powers most of the web. TCP is reliable and self-regulating, but those same qualities mean a single connection rarely uses all the bandwidth available to it. There are three big reasons for this.

Congestion control. TCP doesn't start at full speed. It begins cautiously and ramps up, probing for how much the network can handle. If it senses any loss, it backs off sharply. On a short download, a single stream may spend most of its life still accelerating and never reach the line's true ceiling.

Window sizing and latency. TCP can only have a certain amount of data "in flight" before it must wait for acknowledgements to come back. That ceiling is the receive window. The maximum throughput of one connection is roughly the window size divided by the round-trip time. So even with a generous window, higher latency to the server caps how fast a single stream can go. This relationship is why one connection over a long-distance path can feel sluggish even on a gigabit line.

Per-connection bottlenecks. Routers, the server's own per-socket limits, and middleboxes along the way can each throttle an individual flow without limiting your line as a whole. A single connection runs into the lowest of all these per-flow limits.

How Parallel Connections Fill the Pipe

Think of your internet connection as a wide motorway. A single TCP stream is one car obeying a cautious speed limit and a long following distance. The road has plenty of room, but one car can't fill it. Add more cars in parallel lanes, and suddenly the road's true capacity becomes visible.

Multiple connections work the same way. Each stream independently ramps up and claims a share of the bandwidth. Where one connection gets stuck behind congestion control, window limits, or a per-flow bottleneck, the others keep pulling data. Added together, they saturate the link and reveal what it can really carry at any one moment. That combined number is far closer to the capacity your real apps experience.

This isn't a trick that inflates results. Parallel streams can't push more data than the line physically allows. They simply stop leaving capacity on the table. A single stream under-measures; several streams measure the whole road.

Why Six Is the Right Number

If more connections measure more capacity, why not use twenty? Because the benefit flattens out fast. The first few extra streams make a big difference, filling lanes the first connection left empty. After that, you hit diminishing returns: each additional connection contends with the ones already running and adds little to the total. Past a handful of streams you're mostly measuring the same ceiling with more overhead, more server load, and more chances for one slow stream to skew timing.

Six connections sits comfortably in that sweet spot. It's enough to saturate the vast majority of home broadband and mobile links, while staying clear of the point where extra streams stop helping. Just as important, six reflects how the real world already behaves. Web browsers and apps routinely open several connections at once to load a page or pull down a file — fetching images, scripts, and data in parallel. By using a similar number of streams, our test mirrors genuine usage rather than an artificial best case or worst case.

Measuring Against Nearby Servers

The number of connections is only half the story. Distance matters too. Because a single connection's throughput depends on round-trip time, testing against a faraway server inflates latency and drags results down for reasons that have nothing to do with your line. PingKit measures against nearby, well-provisioned servers so latency stays low and the result reflects your connection rather than the length of the path.

Low latency to the test server keeps each of the six streams ramping up quickly and holding a large effective window, so they reach full speed in the short window of a test. If you're curious about the latency side of the picture on its own, our ping test measures round-trip time directly, and an MTR run shows you latency and packet loss at every hop along the route.

What This Means for You

Understanding the design lets you trust the number you see — and act on it.

• Trust your result. A multi-stream measurement against a nearby server is a fair reflection of your line's real capacity, not an artificially low single-stream reading.
• Compare to your plan. Line up the result against the speed your ISP advertised. A modest gap is normal — advertised speeds are usually "up to" figures. A large, consistent gap is worth investigating.
• Spot throttling. If general downloads are fast but a specific service is slow, or speeds collapse only at certain times, that pattern can point to throttling. Our guide on how to tell if your ISP is throttling walks through how to confirm it.

Honest Caveats

No speed test is the whole truth, and it's worth knowing what can move the number.

• Wi-Fi vs. wired. Wi-Fi is often the real bottleneck, not your line. Distance from the router, interference, and an older device's radio can all cap throughput well below your plan. For the cleanest reading, test on a wired connection where possible.
• Server load. A busy or distant test server can limit results regardless of your line. Running the test more than once helps rule this out.
• Time of day. Networks get congested during peak evening hours. A result at 8pm can look very different from the same test at 6am.
• It measures the path, not just your line. A speed test reflects everything between your device and the server — your Wi-Fi, your router, your ISP, and the wider internet. A slow result locates a problem somewhere on that path; it doesn't automatically pin the blame on your provider.

If you mostly test on iPhone, our walkthrough on how to test internet speed on iPhone covers how to get a clean, repeatable reading on a phone.

Catching Slowdowns Over Time With Guardian

A single test tells you how things look right now. The harder problems — evening congestion, a connection that slowly degrades over weeks, or throttling that only kicks in under certain conditions — only reveal themselves over time. One-off tests will almost always miss them.

That's where Guardian comes in. With Guardian, PingKit can run scheduled speed tests automatically through the free Mac Agent, recording results across hours and days while you get on with your life. Instead of a single snapshot, you build a history you can scroll through and compare. When a slowdown shows up, you'll have the timestamps and the trend to back it up — whether you're reassuring yourself it was a one-off or making a case to your ISP.