The mistake: treating all satellite links as equally slow
ETOs often configure TCP acceleration or latency-compensation middleware on every satellite circuit by habit, having learned on GEO systems. Applied blindly to a LEO circuit, some of those tools actively reduce throughput. The root cause is failing to match the tool to the orbit's actual latency profile.
Altitude drives latency
Three orbit families are in common yacht use:
| Orbit | Altitude | Typical round-trip time |
|---|---|---|
| GEO | ~35,786 km | ~500–600+ ms |
| MEO | ~8,000 km | ~130–150 ms |
| LEO | ~550–1,200 km | ~25–60 ms |
Signal travel time is the dominant factor. GEO satellites are fixed above the equator at 35,786 km; the resulting round-trip time — once the uplink, downlink and ground-station hops are counted — is roughly 500–600+ ms.
MEO satellites orbit much lower. SES markets its O3b mPOWER MEO system specifically on a figure of about 150 ms of predictable latency — a meaningful improvement for business applications, and close to the ~130–150 ms range the research cites for MEO generally.
LEO constellations at 550–1,200 km bring round-trip times down to roughly 25–60 ms, broadly comparable to a busy terrestrial broadband connection.
Why GEO latency hits throughput hard
TCP's slow-start and congestion-window mechanisms were designed for low-latency paths. Each acknowledgement cycle takes one full round-trip time; at 600 ms, the congestion window grows very slowly, leaving a high-bandwidth GEO pipe chronically underutilised. WAN acceleration or TCP spoofing addresses this by locally acknowledging segments and pacing the sender independently of the long path. On a LEO link with sub-60 ms RTT, TCP behaves far closer to a terrestrial session, and those same acceleration tools may interfere with normal congestion-window operation, potentially cutting throughput rather than improving it.
LEO: low latency, added jitter
LEO satellites are not geostationary — they move across the sky continuously. The terminal must hand off between satellites as they rise and set, and each handoff can add 20–40 ms of jitter. For voice and real-time video this matters: a session averaging 40 ms RTT may still experience occasional latency spikes. Jitter buffers in VoIP gateways need to be sized accordingly, and network monitoring should track jitter alongside average latency.
Practical takeaway for the ETO
- Identify which orbit your installed system uses before adjusting TCP or QoS settings.
- GEO: expect and compensate for high, stable latency.
- MEO: moderate, predictable latency; check vendor SLA for the specific system.
- LEO: low average latency but variable; monitor jitter and configure VoIP buffers to suit.