What you'll take away
- Decide an orbit from your applications' delay tolerance, before discussing throughput
- Estimate real user experience by multiplying round trips per transaction by RTT
- Recognise a TCP tuning fault instead of buying capacity you do not need
- Ask five specific questions of any satellite provider before signing
Why latency, not bandwidth, decides most remote-site architectures
Ask what a remote site needs and the answer usually comes back in megabits. It is the wrong question first. A drilling platform running SCADA telemetry, a field hospital on a video consult and a camp of two hundred people streaming in the evening all fit inside the same nominal throughput — and behave completely differently depending on how long a packet takes to make the round trip.
What the physics actually forces
Geostationary orbit sits at roughly 35,786 km. Light needs about 120 ms to cover that distance one way, so a signal that goes up, down, and back again has spent close to half a second in transit before any equipment has done anything useful with it. Nothing in the ground segment can recover that; it is a property of the geometry.
Where the delay actually hurts
Latency is not uniformly damaging. It punishes protocols that talk in many small exchanges and barely touches ones that stream. The practical division looks like this.
| Workload | Sensitivity | What breaks first |
|---|---|---|
| Interactive voice / video | High | Conversational overlap above ~300 ms one-way |
| Chatty application protocols | High | Each round trip multiplies; a 40-exchange handshake costs 26 s at GEO |
| Real-time control loops | Critical | Loop stability — often simply not viable over GEO |
| Bulk file transfer | Low, once tuned | Untuned TCP window, not the link itself |
| Streaming and email | Very low | Nothing meaningful |
The TCP problem, and why acceleration exists
Standard TCP throughput is capped by the bandwidth-delay product: the sender can only have one window of unacknowledged data outstanding. With a default 64 KB window and a 650 ms round trip, the ceiling is roughly 0.8 Mbps — on a link sold as 20 Mbps. Window scaling raises the ceiling, and a performance-enhancing proxy sidesteps the problem by acknowledging locally and managing the long leg itself. This is why a satellite link that "tests slow" is very often a tuning fault rather than a capacity fault.
What it means in the field
On an oil and gas installation or a mining camp, the useful move is to stop treating the link as one pipe and start sorting traffic by its tolerance for delay. Control and safety traffic gets a committed, low-jitter allocation. Bulk replication runs on whatever is left, at night. Anything conversational gets prioritised and, where a second path exists, routed over the lower-latency one. A hybrid design that puts SCADA on a low-latency path and backups on cheaper GEO capacity almost always beats buying more of a single kind of bandwidth.
Practical takeaway: five questions before you specify a link
- What is the longest tolerable round trip for your most delay-sensitive application? Answer this before discussing megabits. It eliminates whole orbit classes immediately.
- How many round trips does your key application make per transaction? Multiply by the RTT. That number, not throughput, is what the user will experience.
- Is the quoted rate committed or contended? Ask for the CIR and the contention ratio in writing, not the headline figure.
- Is TCP acceleration included, and where does the proxy sit? An untuned link can deliver a fraction of what you paid for.
- What availability target does the design assume, in which rain zone? 99.5% and 99.9% are different antennas, different power and materially different cost.
What this article does not settle
The latency figures here are representative ranges for planning, not commitments. Real round-trip time on a specific link varies with elevation angle, hub and modem architecture, the terrestrial tail between teleport and internet peering, and instantaneous load. Measure your own path before designing against a number from any article, including this one.
Conclusion
Bandwidth is the number on the contract; latency is the number your users feel. Sorting traffic by delay tolerance, tuning TCP properly, and matching orbit to workload will do more for a remote site's usable performance than an upgrade to the next capacity tier. The link you already have is often faster than it appears.
Frequently asked
Why is geostationary satellite latency around 600 ms and not 240 ms?
The 240 ms figure counts only the two 120 ms one-way propagation legs. A full round trip adds modem and hub processing, framing and scheduling delay in the TDMA burst plan, and the terrestrial tail between teleport and peering point, which together typically bring it to roughly 600–700 ms.
Does TCP acceleration make a satellite link as fast as fibre?
No. Acceleration removes the throughput penalty that long round trips impose on unmodified TCP, so a link can reach its rated capacity. It cannot reduce the underlying propagation delay, so interactive and control-loop workloads remain limited by the physics.
When is GEO still the right choice over LEO?
Where coverage stability, a fixed pointing angle, predictable capacity contracts and mature regulatory approval matter more than latency — and for bulk, streaming and batch workloads that are not delay-sensitive. Many sites are best served by both, arbitrated by SD-WAN.
Vizocom designs and operates multi-orbit VSAT links for remote operations across 28+ countries — see our VSAT services.