Industrial Protocols. Bench Measurement
Measured on Our BenchMeasuring Latency, Jitter and Packet Loss on an EtherCAT Bus
19.2 µs average round trip · jitter ≤ 1 µs · 0% packet loss
TI Sitara AM572x IDK · TI-RTOS · Acontis EC-Master v3.2 · TMS320F28388D
01Problem
Why EtherCAT? Where Standard Ethernet Falls Short
Getting axes on a machine to move together requires data to travel out and back in the same amount of time, every cycle. Standard Ethernet does not guarantee that by construction: a packet enters a switch queue, waits on the OS scheduler, and its arrival time moves with load. EtherCAT removes both sources of uncertainty, a single frame traverses the whole bus, each slave processes its own data in hardware as the frame passes through, and there is no switch in the path. We built the bus and measured how well that holds up in practice.
- 01On standard Ethernet, arrival time depends on switch queueing and OS scheduling, there is no guaranteed per-cycle budget
- 02When a queue overflows, packets drop; retransmission spikes latency and the control loop misses a cycle
- 03Protocols that send a separate packet per device grow cycle time linearly with device count
- 04The TCP/IP stack is heavier than cyclic process data needs, header overhead and copying lengthen the critical path
- 05Proprietary fieldbus hardware solves determinism but ties you to a vendor ecosystem and raises cost
02Bench Setup
03Measurement Results
One cycle on the bus
The master puts a frame on the bus; each slave reads and writes its own data “on the fly” as the frame passes through. The frame returns to the master from the end of the line. What we measure is the time from the start of transmission to the last byte coming back.
Compared to standard Ethernet
| Metric | Standard Ethernet | EtherCAT (our measurement) |
|---|---|---|
| Jitter | Not guaranteed, varies with switch queueing and OS scheduling | 1 µs maximum |
| Packet loss | Packets drop on queue overflow; retransmission spikes latency | 0% across our measurements |
| Data latency / cycle time | Variable under load; can reach the millisecond range | 19.2 µs average, flat from 1 kHz to 10 kHz |
The EtherCAT column is measured on our own bench. The Ethernet column is not our measurement, it describes the structural behaviour of a standard switched Ethernet/TCP-IP stack and is given for reference.
Effect of payload size on latency
1 slave · 10 kHz · bidirectional payload size
Payload size is the dominant factor. Most of the time is spent transmitting on the wire; a Gb/s interface instead of 100 Mb/s pulls this down directly.
| Payload | Min | Average | Max | Total | Bandwidth |
|---|---|---|---|---|---|
| 32 B | 17.40 | 18.00 | 27.70 | 24.30 | 5.798 Mb/s |
| 64 B | 18.50 | 19.20 | 29.10 | 25.50 | 8.230 Mb/s |
| 128 B | 20.40 | 21.20 | 32.10 | 27.30 | 13.122 Mb/s |
| 512 B | 33.20 | 34.10 | 43.40 | 40.30 | 42.419 Mb/s |
| 1024 B * | 49.60 | 50.60 | 62.00 | 56.80 | 54.321 Mb/s |
* Bidirectional payload exceeds a single EtherCAT frame, so it is split across two frames. Values are for one of the two frames, and the cycle frequency was lowered for stable transport (1024 B → 6.6 kHz, 2×512 B → 5 kHz).
Effect of slave count on latency
2 slaves · 10 kHz · bidirectional payload per slave
At equal total payload the second slave adds only 0.1 µs to the average (2 × 32 B: 19.3 µs vs 1 × 64 B: 19.2 µs), below the ~1 µs per slave that Acontis quotes.
| Payload | Min | Average | Max | Total | Bandwidth |
|---|---|---|---|---|---|
| 2 × 32 B | 18.50 | 19.30 | 33.30 | 25.50 | 8.230 Mb/s |
| 2 × 64 B | 20.40 | 21.20 | 35.10 | 27.40 | 13.122 Mb/s |
| 2 × 128 B | 24.50 | 25.50 | 40.00 | 31.80 | 22.888 Mb/s |
| 2 × 512 B * | 49.50 | 50.50 | 64.30 | 56.70 | 40.740 Mb/s |
* Bidirectional payload exceeds a single EtherCAT frame, so it is split across two frames. Values are for one of the two frames, and the cycle frequency was lowered for stable transport (1024 B → 6.6 kHz, 2×512 B → 5 kHz).
Effect of cycle frequency on latency
1 slave · 64 B bidirectional
From 1 kHz to 10 kHz the average latency moves from 19.7 µs to 19.2 µs, flat in practice. Running a faster cycle does not cost latency.
| Frequency / cycle | Min | Average | Max | Total | Bandwidth |
|---|---|---|---|---|---|
| 1 kHz · 1000 µs | 19.10 | 19.70 | 28.50 | 26.10 | 0.823 Mb/s |
| 2 kHz · 500 µs | 18.60 | 19.40 | 29.30 | 25.70 | 1.646 Mb/s |
| 5 kHz · 200 µs | 18.50 | 19.20 | 28.70 | 25.50 | 4.115 Mb/s |
| 10 kHz · 100 µs | 18.50 | 19.20 | 30.90 | 25.50 | 8.230 Mb/s |
04What These Numbers Mean
The bus we measured delivers a predictable per-cycle budget on standard Ethernet hardware: data travels out and back in 19.2 µs on average over a 100 Mb/s link, and 25.5 µs is what the application actually sees once master software time is included. What matters is less the size of these numbers than how little they move, for a control engineer, being the same every cycle is worth as much as being small.
- 01Raising the cycle from 1 kHz to 10 kHz does not cost latency, a faster control loop is free here
- 02A second slave adds 0.1 µs to the average; cycle time does not balloon linearly as the bus grows
- 03Payload size is the dominant factor, trimming the PDO map buys time directly
- 04Replacing the 100 Mb/s link with a Gb/s interface pulls transmission time down directly; the slave ESC on this bench is capped at 100 Mb/s
- 05Standard Ethernet PHY instead of proprietary fieldbus silicon, supply flexibility and BOM cost preserved
To evaluate your Industrial Protocols. Bench Measurement needs on your own platform, schedule an embedded architecture audit or scope your platform class with the system requirements calculator.
Methodology and Scope
- Measurements were taken on the master device; values describe the frame that traverses the entire bus
- Latency is the time from the start of transmission to the last byte returning. The “Total” column adds the average master software execution time on top
- Jitter (slave synchronization error) is at most 1 µs; this is not the same as the min–max span in the latency tables
- The master stack is EC-Master v3.2 Class B and does not use distributed clocks (DC), which is why we publish no DC synchronization figure
- No packet loss was observed in nearly all tests. The exception is where bidirectional payload exceeds a single EtherCAT frame; lowering the frequency restores stable transport
- The standard Ethernet comparison is not our measurement; it describes the protocol's structural behaviour and is labelled as such in the table
- Results are not final, they vary with the board, the application code and the bus layout
Facing cycle-time or synchronization problems on your bus?
Free technical assessment, let's review the latency and determinism challenges in your system together.
Performance data was measured on our own bench, in the setup documented above. Test conditions and the raw tables are published on this page; the methodology document is available on request.