How to Measure Cellular Latency and Throughput at a Site

Baseline Latency and Its Jitter

Measure round-trip time from the gateway to the destination that matters, which is your SCADA host, not a generic public server, because the path to your host is the one your traffic actually takes. Send timed round trips and record not just the average but the spread, because a link with a decent average latency but wild jitter behaves worse for polling than one with a slightly higher but steady latency. Jitter is the variation from one round trip to the next, and it is what makes a poll response arrive late enough to look like a timeout even though the link is up; the concept is covered in the guide to jitter in SCADA networks.

Take enough samples to see the variation, because a handful of quick pings can miss the periodic spikes a cellular link produces under contention. Watch for the pattern where most round trips are fast but occasional ones are far slower, which is the signature of a congested or handing-off cell. That worst-case tail, not the average, is what your poll timeout has to survive, so record the range you observe, not a single lucky number.

Baseline Throughput to Your Host

Throughput is how much data the link moves per unit time, and for SCADA it is usually the limiting factor only during bursts like a store-and-forward backlog replay or a firmware push, not during routine polling. Measure it by moving a known amount of data to or from your host and timing it, then repeat to see how consistent it is. On low-power cellular families the throughput is deliberately modest, which is fine for telemetry but sets a real ceiling on how fast a large backlog can drain; the trade-offs are described in the overview of LTE Cat-M1 and the comparison in NB-IoT versus LTE-M for IIoT.

Interpret throughput in the context of what the site needs. Routine polling moves little data, so a modest, steady throughput is entirely adequate, and chasing a higher-bandwidth technology for a slow-polling telemetry site is usually wasted money and power. Where throughput matters is recovery: after an outage, the backlog has to drain over this link, and a thin pipe means a long back-fill. Knowing the real throughput lets you size the buffer and set expectations for how quickly a site catches up, which ties back to configuring store-and-forward on the gateway.

Record the Numbers and Match the Design

Write down the typical and worst-case latency, the jitter, and the throughput you measured, along with the band and signal at the time, because these numbers only mean something in context. This becomes part of the site baseline, and it is the data that justifies the poll interval and the timeout settings: a link with high worst-case latency needs a generous poll timeout, and a link with thin throughput needs a bigger buffer and patience during backlog drains.

Match the polling and control design to what you measured rather than to what you hoped for. Setting a fast poll and a tight timeout on a link whose worst-case latency exceeds that timeout guarantees intermittent failures that look like drops but are really the design outrunning the link. The measurement is what keeps the design honest.

Once live, a platform such as Merobix trends the site's connectivity and responsiveness, so a link whose latency creeps up or whose throughput sags against your recorded baseline is flagged as degrading before it starts causing poll failures. The measurement characterizes the link at commissioning; the trend watches whether it holds the performance you designed around.

Frequently Asked Questions