
A live STARLINK-1216 pass over Aberdeen: round-trip delay swings 4–10 ms (left), the same delay overruns the HARQ pool at higher numerologies (middle), and TCP needs window scaling once the end-to-end path grows (right).
Hi all,
Quick one this week, and a slightly counter-intuitive one.
The whole selling point of Starlink-style low-orbit satellites is that they're close — about 550 km up, versus 36,000 km for the old geostationary birds. Close means low delay, and low delay is why LEO can do things GEO never could. So when I set out to measure the latency on a real pass, I half expected to write "it's small, moving on."
It is small. Over a real Starlink pass at my Aberdeen station, the round trip up to the satellite and back ran between about 4 and 10 milliseconds. That's in the same ballpark as regular 5G. No drama.
But then I followed that little delay into two places that quietly assume it'll be tiny — and it got interesting.
[Plot goes here — with the caption below.]
Caption: A live STARLINK-1216 pass over Aberdeen: round-trip delay swings 4–10 ms (left), the same delay overruns the HARQ pool at higher numerologies (middle), and TCP needs window scaling once the end-to-end path grows (right).
The first is how 5G re-sends data that didn't arrive (a thing called HARQ). It works through a limited number of parallel "slots," and the faster 5G runs, the more of those slots the same delay eats up. So the exact same 10-millisecond delay is perfectly fine in 5G's slow mode and completely overwhelms the standard setup in its fast mode. The satellite folks at 3GPP clearly ran into this — their satellite standard specifically doubled the number of slots and added an option to switch the whole re-send mechanism off. My little experiment landed right on the reason they had to do that.
The second is plain old internet connections (TCP). For the satellite link on its own, the delay is small enough that everything's fine. But once you add the rest of the path — down to the ground station, across the backhaul — the delay grows enough that a normal connection can't fill the pipe unless it's specifically configured to. The link is fast and long, and the software has to know that.
So the honest takeaway: being in low orbit solves the big, obvious latency problem — but not the subtle structural ones. The small delay is small enough to ignore in a signal budget and just big enough to reshape the layers above it.
Ten down, two to go. Next up: pulling all ten weeks together into one tool — the flagship's finally getting built.
In plain English, if the jargon lost you: Starlink satellites are close, so the delay in the signal is only a few milliseconds — tiny. But tiny isn't zero, and it turns out that small delay is still enough to trip up two things: the way 5G re-sends data it lost (especially in its fastest modes), and the way normal internet connections work over long links. Being in low orbit fixes the big delay problem but leaves these smaller, sneakier ones — which engineers have to design around.
Full write-up on Medium: https://medium.com/@shaifiqbal/the-satellite-is-close-so-why-does-the-delay-still-matter-6f63636d23f2
Code, tests and plots on GitHub: github.com/shaifiqbal/ntn-latency-budget
More next week.
Shaif