Latency Myths in Orbital Compute

“Latency kills orbital compute.”

We hear this constantly. And there’s truth to it-you can’t eliminate the physics of distance. Light takes about 3.3 milliseconds to travel 1,000 kilometers. A LEO satellite at 550km altitude is at least 7ms round-trip away, even with magical zero-overhead communication.

But when people cite latency numbers to dismiss orbital compute, they usually get the analysis wrong. They compare the wrong things, ignore the wrong things, and end up with conclusions that don’t hold.

We built a latency simulator to understand orbital compute latency rigorously. Here’s what we found that surprised us.

Myth 1: “LEO latency is 20-40ms”

This number gets thrown around because it’s the one-hop latency from a ground station to a satellite and back. And yes, for a single uplink-downlink path, 20-40ms is approximately correct.

But nobody’s building orbital compute with single-hop architectures. Real systems need inter-satellite links (ISLs) to route data to the compute node and back. They need processing time. They need ground station backhauling.

When we model realistic architectures, the latency budget breaks down like this:

User to ground station: 1-30ms (depends on where the user is relative to the PoP)
Ground station to satellite uplink: 3-8ms
ISL hops to compute node: 2-15ms per hop, typically 2-4 hops
Compute processing: variable
Return path: symmetric

For a user in New York reaching a compute node over the Pacific, you’re looking at 80-150ms round-trip before processing. That’s not 20-40ms. It’s 3-4x higher.

But here’s the counterpoint people miss: for many users, terrestrial latency isn’t as low as they assume either.

Myth 2: “Terrestrial latency is ~10ms”

If you’re in San Francisco connecting to a data center in San Jose, sure. 10ms or less.

But most users aren’t next to data centers. Global average latency to the nearest major cloud region is 50-80ms. Users in South America, Africa, Southeast Asia, or rural anywhere routinely see 100-200ms latency to cloud resources.

When we model orbital compute latency against actual user-to-cloud latencies rather than best-case terrestrial scenarios, the gap shrinks dramatically.

For a user in Lagos, Nigeria:

Terrestrial to nearest cloud (Europe): 120-180ms typical
Orbital via LEO constellation: 90-140ms achievable

That’s not worse. That’s potentially better-because the orbital path can be more direct than the terrestrial routing.

The “latency kills orbital compute” argument implicitly assumes users are close to terrestrial data centers. For the users who aren’t, orbital can actually improve latency.

Myth 3: “Latency matters for everything”

It doesn’t. Latency sensitivity varies enormously by workload, and the workloads being considered for orbital compute are specifically selected for latency tolerance.

Consider these latency requirements:

Workload	Acceptable RTT
Online gaming	<50ms
Video conferencing	<150ms
Web browsing	<200ms
API calls	<500ms
Batch ML training	Hours
Scientific simulation	Days
Archive processing	Days

The first three categories are interactive-humans waiting. Orbital compute is probably never going to serve these workloads well.

But batch ML training? If your job runs for 72 hours, what’s 150ms of additional latency? It’s less than one part in a million of your total runtime. It literally doesn’t matter.

The workloads under serious consideration for orbital compute-large-scale training, HPC simulation, data processing pipelines-have latency tolerances measured in seconds, not milliseconds. The latency discussion is almost entirely irrelevant for these use cases.

What actually matters: tail latency

Here’s what the latency conversation should focus on but usually doesn’t: variability.

Orbital communication paths have latency that varies with geometry. As satellites move overhead and ground station visibility changes, the optimal routing path shifts. We’ve measured latency variations of 40-60ms over periods of minutes as constellation geometry evolves.

For batch workloads, this doesn’t matter. For workflows with any timing sensitivity, it’s a real problem.

Our simulation work identified the key variable: ground station density. With sparse ground stations, there are moments when the optimal path is significantly worse than average. With dense ground station coverage, there’s almost always a good path available.

The crossover point is interesting: above about 50 globally-distributed ground stations, tail latency collapses toward median latency. Below that, you get fat tails.

This has implications for orbital compute architectures. You can tolerate high median latency if it’s consistent. You can’t tolerate huge variance even if the median is good. System design should optimize for latency stability, not minimum latency.

The bandwidth bottleneck nobody mentions

While everyone focuses on latency, the more binding constraint for many workloads is bandwidth.

Current satellite downlink capacities max out around 1-5 Gbps per terminal. That’s fine for control traffic and results retrieval. It’s completely inadequate for data-intensive workloads where you need to upload terabytes to the compute node.

We modeled a realistic AI training scenario: 100TB training dataset, training run lasting one week. Just getting the data to orbit takes 2-3 days at achievable upload rates. That’s not a minor overhead-it’s a third of your total runtime.

The implication: orbital compute makes sense for workloads where the compute-to-data ratio is very high. Train on 100TB for a week? Marginal. Run inference on a model that’s already in orbit? Better. Process orbital sensor data that never needs to touch ground? Much better.

Latency gets all the attention, but bandwidth is often the actual blocker.

What our simulator does

The RotaStellar latency simulator lets you model end-to-end latency for realistic orbital compute architectures. You specify:

Constellation geometry (or pick from templates for Starlink, Kuiper, etc.)
Ground station locations
User distribution
ISL topology
Processing location

It outputs P50, P95, and P99 latency distributions over a configurable time window, accounting for orbital dynamics.

What we’ve seen from users: the simulator often improves the case for orbital compute rather than hurting it. When you model the actual comparison-realistic terrestrial alternatives, realistic user locations-the latency delta is often smaller than people expected. And for the right workloads, it’s irrelevant anyway.

The honest summary

Orbital compute has higher latency than terrestrial. That’s physics. But:

The gap is smaller than usually quoted once you account for realistic architectures and realistic terrestrial alternatives
For latency-tolerant workloads (which are the only candidates for orbital compute anyway), it doesn’t matter
Latency variability matters more than median latency for system design
Bandwidth is often the actual bottleneck, not latency

Latency isn’t why orbital compute will or won’t work. Economics, reliability, and power are the real variables. Latency is a distraction for the workloads that make sense in orbit.

Try our latency simulator to model your specific architecture. Request access.