What is jitter?

Jitter is the variation in the delay (latency) with which successive data packets or signals reach their destination, compared with the expected, regular moment of arrival. A network with a constant delay of 2 ms is predictable; a network whose delay fluctuates between 0.5 and 4 ms has jitter, even if the average delay is the same. In industrial networks and real-time systems, jitter causes jerky movements, timing errors between machines and, in the worst case, a dropped connection and a stopped plant.

In OT environments, jitter is often more harmful than a high but constant delay. Deterministic protocols such as ProfiNET, EtherCAT and TSN are designed precisely to limit jitter.


🧠 How does jitter arise and how is it defined?

Jitter appears wherever packets have to wait for something that does not take the same time every time: a queue in a switch, a busy processor, a radio channel that is briefly occupied. The IETF prefers the term delay variation, because the word jitter is used differently in different disciplines. Two definitions are in common use:

  • IPDV (inter-packet delay variation) - the difference in delay between a packet and the packet immediately before it. This is the measurement RTP (RFC 3550) uses for the interarrival jitter that tools such as Wireshark display; there the value is also smoothed with a factor of 1/16 per packet.
  • PDV (packet delay variation) - the delay of each packet relative to the fastest packet in the measurement sample. PDV shows how large a buffer needs to be to absorb all the variation.

In automation, people also speak of cycle jitter: the deviation of the moment a cyclic telegram is sent or received from the configured cycle time. A PLC with a 1 ms task that sometimes runs after 1.3 ms has 0.3 ms of cycle jitter before the network even plays a role.


🔄 What is the difference between jitter, latency and packet loss?

Term What it measures Typical OT cause Consequence
Latency Total time from source to destination Number of switches, processing time, distance Slower response, but predictable and possible to compensate
Jitter Variation in that delay Queues, fluctuating traffic, radio, operating system Unpredictable timing, loss of synchronisation
Packet loss Packets that never arrive Full buffers, bit errors, broken links Missing data, retransmissions or a dropped connection

The three are related but not the same. A controller can take a constant latency into account in its tuning; it cannot do that with jitter, because the deviation differs every time. Jitter does not cause packet loss on the network itself, but it does cause effective loss: a packet that arrives too late for the jitter buffer or the receiver’s deadline is as useless to the application as a packet that never arrived.

Jitter is about unpredictability, not about delay as such. That is why deterministic behaviour is the central design goal of industrial networks.


🏭 Why is jitter more dangerous in OT than in IT?

In office IT, a buffer absorbs the variation: a video stream or phone call waits a few tens of milliseconds and then plays back smoothly. For voice, the rule of thumb is a one-way delay of at most 150 ms (ITU-T G.114) and jitter below 30 ms. An OT control loop cannot afford such a buffer, because every millisecond of waiting directly costs control quality.

Application Typical cycle time Tolerable jitter (order) Impact of excessive jitter
Voice and video (IT) 20 ms per packet Up to about 30 ms Choppy audio, absorbed by the jitter buffer
HMI visualisation and SCADA 100 ms – several seconds Tens of ms Delayed or jumpy display of process data
Process control (PID) 10 ms – 1 s A few ms Poorer control quality, overshoot, oscillation
PLC-to-PLC and remote I/O 1 – 10 ms Hundreds of µs Timing errors between machines, watchdog trips
Motion control and servo motors 31.25 µs – 1 ms Below 1 µs Vibration, position errors, irregular movement

The consequences add up. A discrete control algorithm assumes that measurements arrive at fixed moments; if they arrive irregularly, the controller calculates with the wrong time steps. With a motion controller that moves several axes in synchrony, a few microseconds of deviation between axes already causes visible errors in cutting or packaging work. And PROFINET devices monitor cyclic data with a watchdog: if several consecutive cycles are missed, the device switches to a safe state and the connection drops.


🔧 How do industrial protocols limit jitter?

Standard Ethernet is best effort: a switch forwards frames in order of arrival, and a time-critical frame may have to wait behind a large frame that has just started transmitting. A maximum-length frame occupies a 100 Mbit/s link for roughly 123 µs, and a 1 Gbit/s link for roughly 12 µs. That waiting time is exactly the jitter a motion application cannot tolerate. Industrial protocols each tackle this differently:

Technology Approach Typical performance
ProfiNET RT (Conformance Class A/B) Priority via VLAN tag, no TCP/IP stack for cyclic data Cycles typically 1–10 ms, minimum around 250 µs
ProfiNET IRT (Conformance Class C) Reserved time window per cycle, synchronised clocks, switches with IRT support Cycles from 31.25 µs, jitter below 1 µs
EtherCAT One frame passes all slaves on the fly; distributed clocks measure and compensate propagation delays Synchronisation well below 1 µs
SERCOS III and Powerlink Time-controlled access to the medium with fixed time slots Cycles in the range of tens of µs to ms
TSN IEEE 802.1AS clocks, time-aware queues (802.1Qbv), frame preemption (802.1Qbu/802.3br) Bounded latency on standard Ethernet

TSN is the route to convergence: time-critical and ordinary IT traffic share the same cable, while the time-critical traffic gets guaranteed time windows. With frame preemption, a switch can interrupt a large, less important frame to let a critical frame through first. The joint IEC/IEEE 60802 profile specifies which TSN features industrial devices must support; IEEE approved the profile in March 2026 and the IEC edition followed in June 2026. OPC UA PubSub over TSN and PROFINET over TSN build on this foundation.

All of these mechanisms rely on accurate time synchronisation. The Precision Time Protocol (IEEE 1588, PTP) keeps clocks aligned to within a microsecond; the simpler NTP typically achieves milliseconds and is therefore unsuitable for motion control.


🔐 What causes jitter and how do you address it?

Cause Measure
Queues in non-deterministic switches Industrial switches with QoS, IRT or TSN support
Network congestion from broadcasts, backups or cameras Network segmentation and VLANs, office traffic separated from control traffic
Long frames ahead of critical frames Higher link speed, frame preemption, time-aware queues
Too many switches in a line topology Limit the topology, let the protocol compensate propagation delays
Software timing in PCs, gateways and virtualisation Real-time operating system, dedicated CPU cores, hardware timestamps
Interference and channel access on Wi-Fi Cabling for fast control loops; wireless only for less time-critical data
Security appliances that inspect packets No inline inspection on time-critical paths; measure passively via a TAP

Wireless networks deserve separate attention. Ordinary Wi-Fi uses random back-off times for channel access and therefore has inherent jitter. WirelessHART uses a strict schedule (TDMA with 10 ms time slots) and is therefore predictable, but with update rates typically measured in seconds it is intended for process measurement and monitoring, not for fast control. With URLLC, 5G promises 99.999% reliability within 1 ms for small packets, but that performance depends heavily on how the network is set up and has to be demonstrated in practice.


📏 How do you measure and monitor jitter in practice?

A structured approach in five steps:

  1. Define the requirements - determine the cycle time and maximum tolerable jitter for each application; ask the supplier of the controller or drive for these values.
  2. Measure passively - use a TAP (preferably with hardware timestamps) rather than a SPAN port, because a mirror port itself adds jitter to the measured times.
  3. Analyse the spread - look at the distribution of interval times and above all at the outliers (maximum and 99.9th percentile). An average says little; a single outlier can trip a watchdog.
  4. Correlate with events - peaks often coincide with backups, firmware updates, scans or camera streams. Network monitoring shows which traffic passed through the switch at that moment.
  5. Monitor continuously - many industrial switches and PROFINET diagnostic tools report counters for missed or late frames. Include them in your monitoring so that gradual degradation is noticed before the plant stops.

A typical scenario: on a packaging line, servo axes sporadically trip with a communication error. Measurements show that jitter normally stays within a few microseconds but rises to well over a millisecond once an hour. The cause turns out to be a scheduled backup from a camera system on the same network segment. Moving the cameras to their own VLAN with lower priority solves the problem without any new hardware.

Jitter is also a security issue. Unauthorised scans, a malware outbreak or a denial-of-service attack load the network and increase jitter, which can make processes fail even though no controller has been compromised. Never actively scan OT networks without coordination, and treat unexplained jitter peaks as a signal to look further.


❓ Frequently asked questions

What is a normal jitter value for an industrial network?

A normal jitter value depends on the application. For HMI and SCADA traffic, tens of milliseconds of jitter are no problem; for remote I/O with a cycle of a few milliseconds, jitter is measured in hundreds of microseconds; and motion control with PROFINET IRT or EtherCAT requires jitter below 1 microsecond.

Is jitter the same as latency?

No, jitter is not the same as latency. Latency is the total delay of a packet, while jitter is the variation in that delay between packets. A network can have high latency with little jitter, and that is easier for a controller to handle than a low but strongly fluctuating delay.

How do I measure jitter on an OT network?

You measure jitter on an OT network passively, with a network TAP and an analysis tool such as Wireshark or a dedicated PROFINET or EtherCAT analyser. Look at the spread of interval times between cyclic telegrams and especially at the maximum outliers, not just the average.

Does a faster network connection solve jitter?

A faster connection reduces jitter but does not eliminate it. At 1 Gbit/s, waiting behind a large frame takes about ten times less time than at 100 Mbit/s, but queues still build up under congestion; real guarantees require prioritisation, time-aware queues or a deterministic protocol.

Why is jitter a problem for motion control?

Jitter is a problem for motion control because several axes have to process new setpoints at exactly the same moment. Varying arrival times cause axes to drift out of step, vibration and position errors, which is why motion networks use synchronised clocks with deviations below 1 microsecond.

Can TSN prevent jitter completely?

TSN cannot prevent jitter completely, but it can bound it tightly. With time-aware queues (IEEE 802.1Qbv), frame preemption and clocks via IEEE 802.1AS, time-critical traffic gets guaranteed time windows even when other traffic shares the same cable, provided every switch and device in the path supports TSN and is configured correctly.


📌 In summary

Jitter is the variation in delay and therefore the measure of how predictable a network is. In IT, a buffer absorbs that variation; in OT, every unpredictable microsecond costs control quality, synchronisation or even availability. Deterministic protocols such as PROFINET IRT, EtherCAT and TSN, combined with segmentation, QoS, accurate time synchronisation and passive monitoring, keep jitter within the limits the application requires.

Jitter is the enemy of predictability: in OT networks where timing is crucial, jitter must be actively measured, bounded and monitored.