What Is Latency?
When people say a remote site feels slow, they usually mean latency, not bandwidth. Latency is the delay a piece of data experiences on its way through the network - and for SCADA it shapes how quickly you see a reading and how responsive remote control feels. This guide explains latency and why it matters.
Latency in one line: Latency is the time it takes a packet of data to travel from source to destination across a network, usually measured as round-trip time in milliseconds; in SCADA it governs how quickly field readings arrive and how responsively remote commands take effect.
Latency Is Not Bandwidth
Latency and bandwidth are often confused but describe different things. Bandwidth is how much data a link can carry per second - the width of the pipe. Latency is how long a single packet takes to get through - the length of the pipe. A satellite link can have plenty of bandwidth yet high latency, so bulk data flows fine but every request feels sluggish. A link can also have low latency but little bandwidth.
Latency comes from several sources: the physical distance the signal travels, processing and queuing in each device along the path, and retransmissions when a link is noisy. On a remote site, a weak cellular signal that forces retries can drive effective latency far above the link's nominal figure.
Latency by Link Type, and Why It Matters
The transport dominates latency. A good LTE connection typically adds tens of milliseconds of round-trip delay; a geostationary satellite link adds roughly half a second because of the sheer distance to orbit; low-Earth-orbit satellite falls back to tens of milliseconds. Licensed radio latency depends on the network design and poll cycle. Choosing transport is largely choosing an acceptable latency budget.
For monitoring and alarming, modest latency is fine - a reading arriving a second later is rarely a problem, and report-by-exception hides most of it. Latency bites hardest with interactive remote control and fast closed-loop logic, where a half-second delay makes a link unsuitable and control is kept local at the RTU or PLC. A cloud SCADA like Merobix is built around this reality: field control stays local while the cloud handles monitoring, historian, and alarms.
Measuring Latency Honestly
The first measurement everyone reaches for is a ping, and it is a fine start - it gives round-trip time through the network stack at both ends. But SCADA cares about application latency, which stacks more on top: the field device's own processing time, protocol handshakes, queuing in gateways, VPN and encryption overhead, and the poll scheduler's wait before the request is even sent. A link can show a healthy ping while the application-level round trip - command issued to confirmation received - is many times longer. Measure both: ping to characterize the network, and a timestamped request-response at the protocol level to characterize what operators actually experience.
Averages hide the number that matters. A latency figure is a distribution, and for operations the tail is the story: a link whose typical round trip is fine but which stalls badly during retries will feel broken in exactly the moments that matter. Record latency over time, look at the spread and the worst cases, and treat a widening spread - jitter - as an early symptom: on cellular it often precedes outright failures, because it reflects a degrading RF path doing more retransmission work.
Building a Latency Budget
End-to-end delay decomposes into a sum you can reason about: T_total = T_field + T_uplink + T_backhaul + T_processing + T_display. T_field is the device's scan and response time; T_uplink is the radio link's contribution; T_backhaul is carrier and internet transit; T_processing is the server side; T_display is however long the client takes to show the result. Writing the budget down, even with rough site-measured numbers, does two things: it shows which term dominates - rarely the one people assume - and it gives every future complaint that the system is slow a decomposition to test against instead of a mood.
Polling multiplies whatever the network contributes. A protocol that needs several request-response transactions to read a site pays the round-trip cost several times per poll, so total poll time is roughly the transaction count times the round-trip time, plus the field device's processing. That arithmetic is why high-latency links reward configurations that minimize transactions - block reads instead of register-by-register scans, and report-by-exception instead of brute-force polling - and why the same site can feel crisp or sluggish depending purely on how the poller is configured.
Diagnosing a Slow Site
- Establish what changed: is the complaint new, and does it coincide with a configuration change, new traffic on the link, or a seasonal RF factor such as foliage or weather?
- Ping from the SCADA host to the site gateway and compare with any historical baseline - this isolates the network from the application.
- Check the radio's signal metrics against their commissioning values; a degraded RF path raises retransmissions, and therefore effective latency, before it drops the link.
- Look for competing traffic: a firmware download, a camera stream, or a misbehaving device sharing the link inflates latency for everything else - a bandwidth problem wearing a latency costume.
- Time the application transaction itself; if the network is clean but the response is slow, the field device or the server is the term that grew.
- Only after these steps, consider the transport itself unfit and revisit the choice with a comparison like cellular versus satellite versus radio.
Designing Around Latency Rather Than Fighting It
The robust pattern in remote SCADA is to place functions where latency cannot hurt them. Anything with a tight deadline - control loops, safety actions, interlocks - executes locally at the site, where the loop never crosses the WAN. The WAN then carries only traffic that tolerates delay: measurements, events, history backfill, configuration. Under that division, latency stops being a correctness problem and becomes a comfort problem - it affects how fresh the picture is, not whether the process is controlled.
Two design habits follow. First, timestamp data at the source, so a reading delayed in transit still lands at the correct point in the historian instead of shifting the record; late data is recoverable, mislabeled data is not. Second, make command feedback explicit: an operator sending a command over a slow link should see a distinct in-progress state and then a field-confirmed state, so a long round trip reads as working rather than ignored - the difference between a patient operator and a doubled command.
Frequently Asked Questions
What is the difference between latency and bandwidth?
Bandwidth is how much data a link can carry per second; latency is how long a single packet takes to travel across it. A link can have high bandwidth but high latency, like satellite, or low latency but limited bandwidth.
Does high latency break SCADA monitoring?
Rarely for monitoring and alarms - a reading arriving a fraction of a second late is fine, and report-by-exception reduces traffic. Latency matters most for interactive remote control and fast closed-loop logic, which is why that control stays local in the field.
What is a typical latency for cellular telemetry?
A healthy LTE link usually adds tens of milliseconds of round-trip latency. A weak signal that forces retransmissions raises the effective figure, which is why signal strength and antenna placement affect responsiveness as much as the carrier's network does.
How do I tell latency problems from bandwidth problems?
Send something small. A ping is tiny, so its round-trip time is almost pure latency; if small transactions are slow, the path itself is slow or lossy. If small transactions are fast but large transfers crawl or time out, the pipe is narrow or congested - a bandwidth problem. The confusing middle case is congestion: a saturated link queues packets, so latency rises as a symptom of a bandwidth shortage. Watching a ping and a bulk transfer together separates the three cases quickly.
Why do my commands feel slow even though readings arrive fine?
Readings are one-way and often batched, so modest delay is invisible. A command is interactive and usually involves multiple legs - request, execution, and a confirmation poll - so the operator experiences several round trips stacked end to end, plus any deliberate select-before-operate exchange the protocol requires for safety. That stacking is why interactive control exposes latency that monitoring hides, and why control with tight timing stays local to the site.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.