Daniel's on an Emirates flight somewhere over the Atlantic, taps the Starlink Wi-Fi, runs a speed test, and immediately thinks — I should share this with the open source community. Which is such a Daniel thing to do. He's got two questions for us. First, what are the real pitfalls when benchmarking internet speed at home — the server you pick, the wired connection myth, ISPs gaming their own tools. Second, what's happening with in-flight Starlink benchmarks, what are people actually finding up there, and how much does the aircraft's own equipment matter versus the satellite link. So today we're unpacking what a speed test actually measures — and what it hides.
And the timing's good, because Starlink's aviation rollout is hitting this inflection point where the installs are spanning everything from regional jets to A380s, and the community benchmarks are starting to paint a real picture — messy, inconsistent, but real.
Let's start with the basics. What is a speed test actually doing when you hit that button?
It's not one measurement. It's a chain. Your device talks to your router, the router talks to your modem, the modem hits the ISP's network, and then that traffic gets routed across potentially several backbone networks before it reaches whatever server you're testing against. The test itself is usually a quick download and upload of a file — or multiple parallel streams — and it times how long that takes. The number you get is the throughput across that entire chain at that exact moment.
And any link in that chain can be the bottleneck.
Right. And most people don't realize how many links there are. Your phone's Wi-Fi chip is a link. The router's CPU is a link. The cable between the router and the modem. The modem's firmware. The ISP's local node, which might be congested because your neighbor is seeding seventeen Linux ISOs. Then the peering point where your ISP hands off to the backbone, then the server itself, which might be handling ten thousand other tests simultaneously.
So the number on the screen is a biography of everything that happened to those packets, not a property of your internet connection.
That's exactly the right way to put it. The speed test result is a story about a journey, not a fact about the pipe.
Alright, let's tackle the home environment first, where you'd think it's easy.
It should be easy. You plug in Ethernet, you close every other app, you run the test. And yet.
And yet the numbers don't add up.
The first thing people miss is that a wired connection doesn't remove the router from the equation. If your router has a weak CPU — and a lot of consumer routers do — it might not be able to process packets fast enough to saturate a gigabit connection. The Ethernet port says one gigabit, but the processor inside is choking on NAT translations and firewall rules and QoS packet inspection, and suddenly your wired speed test caps at six hundred megabits.
So the wire is only as good as the box it's plugged into.
And the box's settings. QoS — quality of service — is designed to prioritize certain traffic. If it's misconfigured, or if it's doing deep packet inspection on every speed test packet, you lose throughput. I've seen cases where turning off QoS added two hundred megabits to a wired test.
What about the modem? Most people rent whatever box the ISP gives them.
That's where it gets interesting — and where the ISP manipulation angle comes in. A lot of ISP-provided modem-router combos have a built-in speed test tool. You log into the modem's admin page, click a button, and it tells you you're getting nine hundred fifty megabits on your gigabit plan.
And people feel good about that number.
They feel great. The problem is that modem's built-in test isn't measuring your internet connection. It's measuring the link between the modem and the ISP's first node — sometimes literally the device sitting in the street cabinet. It bypasses your router entirely, it bypasses your home network, and it's testing against a server that's physically close and on the ISP's own backbone. It's like measuring how fast your car goes by only driving from your driveway to the end of the street.
And the ISP's own speed test website — the one you visit in a browser — can be rigged the same way.
Some ISPs prioritize traffic to their own speed test servers. They exempt it from any throttling or traffic shaping that applies to normal data. So your Netflix traffic might be getting shaped down during peak hours, but the speed test packets get a fast lane. The result looks perfect, and the customer thinks the problem is Netflix.
So how do you actually detect that?
You test against multiple third-party servers. Run a test on the ISP's tool, then immediately run one on Ookla's Speedtest against a server that's not on your ISP's network, then run Cloudflare's speed test. If your ISP tool shows nine hundred megabits and Cloudflare shows three hundred, something is being prioritized.
That's not a subtle discrepancy.
It's not, and I've seen exactly that spread. There was a case documented on a networking forum where a user on a one-gigabit plan was getting nine-fifty on the ISP's tool and around four hundred on third-party servers. The ISP had been prioritizing speed test traffic to their own servers and shaping everything else. The user only caught it because they noticed video calls were struggling despite the speed test saying everything was fine.
So the speed test was gaslighting them.
Effectively, yes. And that's before we even get to server selection. Most speed test tools let you pick which server you test against. If you pick one that's geographically close and on the same ISP's backbone, you'll get a great number. If you pick one across the country on a different network, you're also measuring the peering arrangements between ISPs.
Explain peering for a second.
When traffic leaves your ISP's network and enters another — say, to reach a server hosted on a different provider — it crosses a peering point. These are interconnection points where networks exchange traffic. Some peering arrangements are generous and well-provisioned, some are congested and contentious. ISPs have been known to let peering points get overloaded rather than pay to upgrade them, because the congestion makes the other guy's service look bad.
So your speed test result might actually be telling you about a business dispute between two companies you've never heard of.
And you, the user, just see a slow number and blame your internet.
Bufferbloat. You mentioned that earlier. What is it?
Bufferbloat is when your router has too much buffer memory and holds onto packets too long instead of dropping them. It sounds counterintuitive — you'd think bigger buffers are better — but when the buffer fills up, it introduces latency. Packets sit in the queue waiting their turn. For a speed test, which is just blasting data in one direction, bufferbloat can actually make throughput look fine while destroying responsiveness. You'll get a great download number but your web browsing feels sluggish, because every small request is waiting behind a queue of speed test data.
So the test says fast, the experience says slow.
And bufferbloat is notoriously hard to diagnose without running a specific test — the DSLReports speed test was one of the few that measured it directly, but that site's been declining. These days, the Waveform bufferbloat test is the go-to.
What about the device itself? Daniel mentioned the phone being a variable.
In a home context, if you're testing on a phone over Wi-Fi, you've already introduced so many variables that the number is almost meaningless for diagnosing your connection. Phone Wi-Fi antennas are small, power management can throttle the radio to save battery, and the OS network stack might not be optimized for throughput. I've seen the same speed test run on a laptop and a phone, same Wi-Fi network, same server, and the phone gets half the speed.
So rule one for home testing: wired, not wireless.
Wired, with a known-good Ethernet cable — because cables do fail, and a bad cable can negotiate down to a hundred megabits without you noticing. Wired directly to the router, not through a switch if you can avoid it, because cheap switches add their own bottlenecks. Close every other application. And then test against at least three different servers on different networks.
That's a lot of ritual for one number.
It is, and most people won't do it. Which is why most home speed test results shared online are... let's say, aspirational.
Alright. Let's take this same question thirty-five thousand feet in the air.
Where everything we just said about controlled conditions goes out the window.
Daniel's on an Emirates flight, impressed by the Starlink Wi-Fi, wants to share a benchmark. What's he actually measuring when he taps that button?
He's measuring his phone's connection to the aircraft's internal Wi-Fi access point, which is connected to the aircraft's network, which is connected to the Starlink terminal mounted on the fuselage, which is connected to a satellite moving at seventeen thousand miles an hour, which is connected to a ground station, which is connected to the internet. And every single one of those links is a variable.
And he can't control any of them.
He can't even see most of them. The phone is the first problem. Like we said — Wi-Fi antenna, power management, OS stack. But on a plane, you've also got the phone's modem searching for cellular signals that don't exist, which can cause background processes that eat CPU cycles. Some phones handle airplane mode differently — they might keep certain radios partially active. It's a mess.
So two people on the same flight, same phones, could get different results just based on where they're sitting.
Distance from the access point matters. If you're sitting directly under one, you'll get a stronger signal than someone at the back of the cabin. The aircraft's internal Wi-Fi deployment is a whole engineering challenge — you're running access points in a metal tube with hundreds of human bodies absorbing signal. The placement, the number of APs, whether they're Wi-Fi six or older, how the airline has configured bandwidth shaping per passenger — all of that shapes the result.
And then there's the Starlink terminal itself.
This is where the equipment really matters. Starlink's aviation terminals use phased array antennas — flat panels that steer the beam electronically rather than mechanically pointing a dish. The newest installs, as reported by PaxEx dot Aero, are going onto everything from regional jets to widebody A380s. But the terminal on a brand-new Emirates A380 is not the same as the terminal on a five-year-old regional jet that got retrofitted last month.
So same satellite constellation, different hardware on the aircraft, different results.
And the community benchmarks are bearing this out. I've been following the threads on Reddit and the flight-testing forums. On an Emirates A380, people are reporting speeds between a hundred and a hundred eighty megabits down. On a regional jet with an older install, that same Starlink constellation is delivering twenty to forty megabits.
That's a huge spread.
It is, and it's almost certainly not the satellite link that's the bottleneck. The Starlink constellation can push far more than that to a single terminal. The bottleneck is the aircraft's internal network — the Wi-Fi deployment, the bandwidth management, and most importantly, the shared pipe.
The shared pipe being the fact that you're splitting that satellite link with everyone else on the plane.
Two hundred people, all checking email, streaming video, doomscrolling. The speed test is a snapshot of whatever capacity is available to you at that exact second. If the person in 14A just started a Zoom call, your test result drops. If the captain just turned on the system and you're the first one testing, you'll get a heroic number.
So the speed test on a plane is even less representative than at home.
Wildly less. At home, you can at least control the endpoint. On a plane, you're measuring a moment in a constantly shifting environment. And yet — the community benchmarks are still useful.
How?
Because if you aggregate enough of them, patterns emerge. If a hundred people on Emirates A380 flights consistently get between a hundred and two hundred megabits, and a hundred people on some other airline's 737s consistently get twenty to forty, that tells you something real about the equipment and the deployment. The individual test is noisy, but the aggregate is signal.
Like polling.
Exactly like polling. One poll is a snapshot with a margin of error. A hundred polls averaged together tell you who's ahead.
What are people actually finding? Which airlines are coming out on top?
Emirates is the clear leader in the benchmarks I've seen. They're deploying Starlink aggressively, and their aircraft — especially the A380s — have modern internal Wi-Fi infrastructure. Qatar Airways is also showing strong numbers. United has been rolling it out on their regional jets and some mainline aircraft, and the early results are promising but more variable.
What about the PCMag report — Starlink hyping multi-gigabit in-flight Wi-Fi?
Right, so SpaceX has been talking about multi-gigabit capability for the aviation terminals, and technically the hardware can support it. The phased array antennas are capable of very high throughput. But that's the link between the terminal and the satellite, in ideal conditions, with no one else on the network. It's a lab number. The real-world passenger experience is always going to be lower because you're sharing that capacity.
The marketing is true in the same way that your car's top speed is true — theoretically achievable, never actually reached in normal use.
The gap between the marketing number and the passenger number is where the community benchmarks do their real work. Without people like Daniel sharing their results, all we'd have is Starlink's claims and the airlines' press releases. The messy, imperfect, uncontrolled data from actual passengers is the only check on that.
There's something almost democratic about that.
There is. And the sites that aggregate this data — the ones where you enter your flight number and speed test result — they're building a crowdsourced map of what's actually happening up there. It's not scientifically rigorous, but it's honest.
What about the aircraft's receiving equipment? You mentioned the phased array — how much does the specific terminal model matter?
A lot. The newer Starlink aviation terminals are more capable than the early ones. They handle satellite handoffs better — remember, these satellites are moving fast, and the terminal is handing off from one to the next every few minutes. A newer terminal does that more seamlessly, which means fewer dropped packets and more consistent throughput. The terminal's placement on the aircraft also matters — it needs a clear view of the sky, and on some aircraft the fuselage curvature or the tail can partially obstruct the field of view.
Then inside the plane, the Wi-Fi deployment is a whole separate procurement decision.
Right. The airline might have a state-of-the-art Starlink terminal on the roof and then feed it into a ten-year-old Wi-Fi system with insufficient access points and aggressive per-passenger throttling. The satellite link could be capable of five hundred megabits, but if the airline caps each passenger at fifteen, that's what you'll get.
The speed test is really measuring the airline's choices, not Starlink's capability.
That's useful information. If you're choosing between two airlines for a long-haul flight and one consistently delivers better Wi-Fi speeds in the community benchmarks, that's a real differentiator. It's not about Starlink versus Starlink — it's about how each airline has chosen to implement it.
You mentioned earlier that you once argued Starlink's vertical integration was a key advantage. How does that play out here?
Starlink owns the satellites, the ground stations, and the terminals. They control the entire stack from the user terminal to the internet backbone. That means they can optimize end-to-end in ways that traditional in-flight connectivity providers can't. The old model was a patchwork — one company makes the antenna, another operates the satellite, a third handles the ground infrastructure, and the airline's IT contractor manages the onboard Wi-Fi. Each handoff is a potential bottleneck and a finger-pointing exercise when something goes wrong.
With Starlink, there's only one throat to choke.
Which doesn't mean everything is perfect — the airline's internal Wi-Fi is still outside Starlink's control — but it removes a lot of the variables. And the community benchmarks are showing that the Starlink-equipped flights are consistently outperforming the older geostationary satellite systems, sometimes by an order of magnitude.
An order of magnitude is not incremental improvement. That's a different product.
It's the difference between in-flight Wi-Fi being a frustrating thing you try once and give up on, versus something you just use, the way you use Wi-Fi in a coffee shop.
You once said that when in-flight Wi-Fi is good enough that you stop thinking about it, it stops being a feature and becomes infrastructure.
I remember you saying that, actually.
Was it me? Alright, I'll take it. But that's the threshold we're approaching. When the speed test stops being something you run out of curiosity and becomes something you don't bother running because the connection just works.
We're not there yet. But the Starlink deployments are getting close. And the community benchmarks are how we'll know when we've arrived.
Hilbert, you've been quiet — you have a story here, don't you?
Hilbert: I installed the first in-flight internet systems. Connexion by Boeing. Late nineties.
Wait, you worked on Connexion? That was the original — Boeing's satellite internet for commercial aircraft.
Hilbert: I was the network engineer for a regional carrier that was one of the early test beds. We had to manually throttle every passenger. There was a console in the avionics bay where you'd set per-seat bandwidth limits. If you got it wrong, one guy downloading a PDF would kill the satellite link for the whole plane.
You had to throttle people by hand.
Hilbert: We had a chart. First class got more. It was a different time.
What kind of speeds were you working with?
Hilbert: The satellite link was about five megabits down, shared across the whole aircraft. The internal Wi-Fi was eight hundred and two eleven b — eleven megabits theoretical, maybe four or five real. And we had to make that work for a hundred and twenty passengers.
The speed test would have been... what, a few hundred kilobits?
Hilbert: If you were lucky. But we didn't have speed tests, not the way you do now. Passengers didn't run them. They just complained.
How did you know if the system was working?
Hilbert: I tested it from the cockpit.
From the cockpit.
Hilbert: Had a laptop I'd plug into the avionics network. Bypassed the passenger Wi-Fi entirely. Direct connection to the satellite modem. I'd get the full five megabits, every time. Perfect speed test. Meant nothing for anyone else on the plane.
That's... that's a perfect metaphor for everything we've been talking about.
Hilbert: That's what I was thinking, listening to you two. The best speed test I ever ran was the one that told me nothing about what the passengers were actually experiencing. They were getting dial-up speeds in row twenty-two and I'm in the cockpit looking at five megabits and thinking the system's fine.
You were the ISP gaming its own speed test, except you were doing it manually, with a laptop, in the cockpit.
Hilbert: I didn't think of it that way at the time. I was just trying to prove the system worked so the airline wouldn't cancel the contract.
Did they cancel it?
Hilbert: Boeing shut the whole program down in two thousand six. Lost a lot of money. I kept the laptop.
Of course you did.
Hilbert: It's in a box somewhere. Still has the Connexion diagnostic software on it. Probably won't boot.
That laptop is a museum piece. The entire history of in-flight connectivity, from five megabits shared across a hundred twenty people to Starlink pushing hundreds of megabits to individual passengers.
Hilbert: The problem's still the same. The test never matches the experience. It's just faster now.
The misconception people hold about all of this — and I think it's the thing that trips up most home users and most passengers — is that a speed test measures your internet connection. It doesn't. It measures a single path through a complex system at a single moment in time. Change the server, change the time of day, change the device, change the seat on the aircraft, and you get a different number. The number isn't wrong — it's just answering a much narrower question than people think.
The second misconception is that ISPs' own speed test tools are reliable. They can be the least reliable of all, precisely because they're designed to show you the one path that makes the ISP look good. The third-party test, the community benchmark, the messy aggregate — that's where the truth lives.
Which brings us back to Daniel, somewhere over the Atlantic, running a speed test on his phone. The number he gets won't be perfect. It won't be scientific. But if he shares it, and a hundred other people share theirs, that aggregate starts to tell a story that no press release ever will.
Next time you run a speed test, remember — you're not measuring the internet. You're measuring a moment.
Thanks to our producer Hilbert Flumingtop for keeping this show running, and for the laptop in a box somewhere that we now all want to see.
This has been My Weird Prompts. If you want to send us your own questions — or your speed test results — email the show at show at my weird prompts dot com.
We'll be back soon.
