Real-time digital twin latency decides whether a twin feels live or laggy, and whether it can safely do more than observe. This article explains realistic latency budgets for visualization, monitoring and control twins, breaks down where the milliseconds actually go, shows how MQTT QoS and broker placement affect delay, and gives you a script to measure end-to-end latency on your own setup.
For background on twins in general, read the digital twin technology guide.
"Real-Time" Means Different Things for Different Twins
There is no single latency requirement for digital twins. The right target depends on what the twin is for:
| Twin purpose | What matters | Typical acceptable end-to-end latency |
|---|---|---|
| 3D or animated visualization | Motion looks continuous and in step with reality | Well under a second; a few hundred ms feels live |
| Operational monitoring dashboards | Operators see changes promptly | About one second to a few seconds |
| Alarming and notifications | Faults are surfaced before someone walks over | Seconds |
| Supervisory control (setpoints, start/stop) | Operator commands take effect quickly and are confirmed | Sub-second to a couple of seconds, with acknowledgement |
| Closed-loop or safety control | Deterministic response | Milliseconds, handled locally, not through a cloud twin |
These are qualitative engineering ranges, not standards. The important lesson is in the last row: closed-loop and safety functions belong in PLCs and local controllers. A cloud-connected twin can supervise, advise and adjust setpoints, but it should never be the only thing standing between a machine and an unsafe state.
Where Real-Time Digital Twin Latency Comes From
End-to-end latency is the sum of every stage between a physical change and the pixel or action that reflects it:
- Sensing and sampling: a value sampled every 500 ms adds up to 500 ms before anyone knows it changed.
- Edge processing: PLC scan cycles, gateway polling intervals and batching.
- Publish buffering: some clients batch writes; deadbands delay small changes by design.
- Network uplink: plant network, internet path, cellular or satellite links.
- Broker processing: authentication is done at connect time; routing a publish to subscribers is usually a small part of the total on a well-run broker.
- Network downlink: from broker to viewer or consumer.
- Application and rendering: parsing, state updates and the next render frame.
In practice, sampling and polling intervals at the edge and network distance dominate. Teams often optimise the broker while a gateway polls the PLC once per second, which caps responsiveness no matter what happens downstream.
How MQTT Settings Affect Latency
QoS Levels
- QoS 0 sends the message once with no acknowledgement. Lowest overhead and the usual choice for high-rate visualization telemetry, where the next sample replaces a lost one.
- QoS 1 requires a PUBACK. Delivery to subscribers is not delayed by the acknowledgement itself, but retransmissions after loss add delay, and in-flight limits can throttle bursts.
- QoS 2 adds a four-step handshake per message. Use it only when exactly-once semantics are truly required, which is rare for twin data.
The MQTT QoS levels explained article covers the mechanics.
Connections and Sessions
Keep connections persistent. Reconnecting for each publish adds TCP and TLS handshakes, which can cost more than everything else combined. Set keepalive so dead connections are detected promptly, and use a last will so viewers see when a device drops instead of trusting stale values.
Payload and Topic Size
Small payloads serialise and transmit faster, especially on constrained links. MQTT 5 topic aliases replace long topic strings with short integers after the first message, which helps deep ISA-95 topic paths on slow uplinks. See MQTT 5 features.
Retained Messages for Perceived Latency
Retained state does not make updates faster, but it removes the worst perceived delay: the wait after opening a twin until every asset has published once. With retained state, the full scene appears immediately on subscribe. The digital twin retained MQTT tutorial shows how.
Broker Placement and Network Distance
Every network hop adds delay, and physical distance adds round-trip time that no software can remove. Practical guidance:
- Place the broker close to where most publishers and consumers are, network-wise.
- If devices are in one plant and viewers worldwide, prioritise the device side for control twins and accept extra viewer delay for visualization.
- For strict requirements, consider a broker inside your own cloud account or region. ConnectMQ offers Dedicated clusters and BYOC deployments in your cloud account, managed by ConnectMQ, for teams that need control over where the broker runs.
- Avoid hairpinning: a plant viewer should not route through a distant region to see a machine three metres away if local latency matters; use a local display fed by the edge for that case.
Measuring End-to-End Latency
Measure before optimising. This Python script publishes timestamped messages and subscribes to the same topic, reporting round-trip latency through the broker. Because the same machine sends and receives, clock skew does not affect the result.
import json
import statistics
import time
import uuid
import paho.mqtt.client as mqtt
TOPIC = f"connectmq/demo/{uuid.uuid4().hex[:8]}/latency"
SAMPLES = 50
results = []
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(TOPIC, qos=0)
def on_message(client, userdata, msg):
sent = json.loads(msg.payload)["t"]
results.append((time.perf_counter() - sent) * 1000)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"latency-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_start()
time.sleep(1)
for _ in range(SAMPLES):
client.publish(TOPIC, json.dumps({"t": time.perf_counter()}), qos=0)
time.sleep(0.2)
time.sleep(1)
client.loop_stop()
client.disconnect()
if results:
results.sort()
print(f"samples: {len(results)}")
print(f"median: {statistics.median(results):.1f} ms")
print(f"p95: {results[int(len(results) * 0.95) - 1]:.1f} ms")
print(f"max: {results[-1]:.1f} ms")
The script sends five messages per second, within the public broker's limit of 10 messages per second per client. Run it from the networks your devices and viewers actually use, at different times of day, and compare QoS 0 with QoS 1. Report percentiles, not just averages: a twin that is fast on average but stalls at the 99th percentile still feels unreliable.
For true one-way device-to-viewer latency, include the source timestamp in every telemetry payload, synchronise clocks with NTP, and compute the difference in the viewer. Show the age of each value in the UI; it is the most honest latency indicator an operator can get.
Latency Optimisation Checklist
- Define the latency budget per twin purpose before choosing technology.
- Shorten edge polling and sampling intervals for signals that drive visuals or control.
- Use QoS 0 for high-rate telemetry and QoS 1 for state changes and commands.
- Keep MQTT connections persistent; avoid connect-per-message patterns.
- Use TLS session settings and keepalive sensibly so reconnects are rare.
- Retain current state so viewers render instantly on load.
- Decouple message handling from rendering and interpolate between samples.
- Measure percentiles from real networks and display value age in the twin.
- Keep safety and closed-loop control local, never dependent on the cloud path.
How ConnectMQ Fits Your Latency Budget
ConnectMQ provides a cloud MQTT broker with persistent MQTT 3.1.1 and 5.0 connections over TCP, TLS, WebSocket and secure WebSocket, so devices and browser twins share one low-overhead path. Retained messages give instant scene loads, MQTT 5 topic aliases trim overhead on deep topic trees, and Dedicated or BYOC deployments let you choose where the broker runs. Our 3D digital twin demo animates a factory live over WSS using exactly these patterns. For context on what an MQTT broker does in this path, see our introduction; for twin data patterns, read digital twin with MQTT and digital twin architecture.
Measure Your Twin's Latency on ConnectMQ
Run the script above against the public broker, then repeat it against your own broker. Create one for free on the Serverless plan at app.connectmq.com, with no credit card, switch to port 8883 with your generated credentials, and compare the numbers from your real device networks.
Frequently Asked Questions
What latency does a real-time digital twin need?
It depends on purpose: visualization feels live at a few hundred milliseconds, monitoring tolerates around a second or more, and closed-loop control needs millisecond responses that belong in local controllers, not cloud twins.
Does MQTT QoS 1 add a lot of latency?
Usually little under normal conditions, because messages are forwarded before acknowledgement completes. Delays appear mainly when packets are lost and retransmitted or in-flight limits are reached.
What is the biggest source of digital twin latency?
Often edge sampling and polling intervals plus network distance, not the broker. Measure each stage before optimising.
How can I show latency to operators?
Include a source timestamp in every message and display the age of each value in the twin, highlighting values that are older than expected.
