Two links can have the same average delay yet feel completely different in practice - one steady and predictable, the other lurching. The difference is jitter: the variation in delay from one packet to the next. It gets less attention than latency, but on wireless SCADA links it can cause the more puzzling problems. This guide explains what jitter is and why it matters.
Jitter in one line: Jitter is the variation in packet delay across a network - the inconsistency in how long successive packets take to arrive, rather than the delay itself. Where latency is the average travel time, jitter is how much that travel time fluctuates. High jitter makes a link's timing unpredictable even when its average latency looks fine.
Latency and jitter are related but distinct. Latency is the delay a packet experiences; jitter is how much that delay changes packet to packet. A link that consistently delivers packets 60 ms apart has 60 ms latency and near-zero jitter - steady and predictable. A link that averages 60 ms but swings between 20 ms and 300 ms has the same nominal latency yet high jitter, and it will behave far worse for anything timing-sensitive.
Jitter matters because many protocols and applications assume a reasonably steady flow. When packets bunch up and then arrive in a burst, a receiver expecting them evenly spaced can misjudge timeouts, trigger unnecessary retransmissions, or reorder data. On a poll-response protocol, wildly variable round-trip times make it hard to set a sensible timeout: set it tight and you get false failures during a jitter spike; set it loose and you are slow to detect a genuinely dead device.
Jitter comes from anything that makes delay inconsistent. Network congestion is a leading cause: when a queue in a router or cellular base station fills and drains, packets wait varying amounts of time. Wireless links add their own sources - a cellular device that ranges between towers, adapts its modulation to changing signal, or contends with other users on the same cell will see delay wander. Retransmissions after radio errors inject sudden spikes. Route changes and variable processing loads contribute too.
This is why a remote site with a marginal cellular signal can show erratic behaviour that pure latency numbers do not explain: the average may be acceptable, but the spikes cause timeouts and reconnects. Improving antenna placement and signal strength often reduces jitter as much as it reduces latency, because fewer radio retries means steadier timing.
For monitoring and alarming, moderate jitter is tolerable - a reading arriving unevenly is still a valid reading, and report-by-exception with buffering smooths over most of it. Jitter bites hardest where timing must be predictable: interactive remote control, tight poll cycles, and any real-time synchronisation. On a jittery link, poll timeouts are hard to tune and the connection can appear to flap even though it is technically up.
The practical response mirrors the response to latency: keep fast, deterministic control local at the RTU or PLC, where the network's timing does not intrude, and let the wide-area link carry monitoring and historian traffic that tolerates variation. A cloud SCADA such as Merobix is built around this - field control stays local while the cloud handles monitoring - so jitter on the cellular or satellite link degrades responsiveness gracefully rather than breaking control. Generous timeouts, store-and-forward, and event-driven protocols like DNP3 and MQTT all help absorb jitter.
Latency is how long a packet takes to travel across a link; jitter is how much that travel time varies from packet to packet. A link can have low average latency but high jitter, meaning its timing is inconsistent even though it looks fast on average.
Congestion at the tower, a device ranging between towers or adapting its modulation, radio retransmissions on a weak signal, and variable queuing all make delay inconsistent. A marginal cellular signal is a frequent cause, so improving antenna placement often reduces jitter as well as latency.
Rarely for monitoring and alarms, which tolerate uneven arrival, especially with buffering and report-by-exception. It matters most for interactive remote control and tight poll cycles, where variable timing causes timeouts and apparent flapping. Keeping fast control local in the field avoids the problem.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.