What is known about the bandwidth and latency of Ethernet/IP?

What are the bandwidth and latency characteristics of EtherNet/IP?

Assessing link speed and machine response together

Hello everyone. There is no single bandwidth or latency figure for EtherNet/IP. Link speed describes how much traffic a link can carry, packet processing capacity describes how many messages a device can handle, and end-to-end response time describes when a field change affects an output. Judging performance from a “100 Mbit/s” label alone overlooks how the protocol works.

Editor's note: RPI is not total latency. Setting a 2 ms RPI does not guarantee a 2 ms response from sensor to actuator. Also, heavy traffic does not cause collisions on a correctly operating switched, full-duplex Ethernet link. Typical concerns are queueing, packet loss and device load.

Bandwidth: port speed, useful data and packet rate

EtherNet/IP uses standard Ethernet infrastructure. 100 Mbit/s and 1 Gbit/s links are found in industrial systems; older devices may use 10 Mbit/s, while backbones may run faster. However, a gigabit switch cannot accelerate a device's 100 Mbit/s port. Headers at the different protocol layers and interframe gaps mean that link capacity is not entirely available for application data. Faulty cables or connectors can also cause errors and interrupted links.

Mbit/s and packets/s are separate limits. Small packets can occupy little bandwidth while placing a significant load on a communications processor. Check the manufacturer's limits for packet rate, connection count and data size together. Low port utilization alone does not establish that the network and controller have enough processing capacity.

Cyclic I/O and parameter traffic behave differently

Implicit I/O messaging carries time-critical process data over UDP, using unicast or multicast as configured for the connection. Explicit messaging generally uses TCP for request/reply operations such as parameter access, diagnostics and configuration. Understanding the port numbers and message types helps identify these flows. UDP itself provides no acknowledgements or retransmissions; CIP supervises the connection. TCP's reliable delivery does not guarantee a fixed delivery time.

What happens when you reduce the RPI?

The Requested Packet Interval, or RPI, specifies the requested packet production interval for a cyclic connection. It does not mean that the PLC polls the device for every update. The interval selected during connection configuration must respect the device's supported limits. With the same data size, changing from 10 ms to 2 ms increases the cyclic flow's packet rate by approximately five times.

Select an RPI that matches the application's actual update requirements. Internal tasks and data refresh cycles also matter. For example, Beckhoff's TF6280 documentation requires the TwinCAT task serving the adapter to run at least as fast as the communication cycle. This product example shows why network settings and control tasks must be considered together in an automation application.

Worked example: 20 remote I/O adapters

Simplified assumptions: Each adapter has one input flow and one output flow, with 100 bytes of application data per packet in each direction and a 10 ms RPI for both directions. For one cyclic flow, packets/s = 1000 / RPI(ms). The PLC therefore receives 20 × 100 = 2,000 packets/s of input traffic and transmits another 2,000 packets/s of output traffic.

The useful data rate is 2,000 × 100 × 8 = 1.6 Mbit/s in each direction, or 3.2 Mbit/s combined. Reducing the RPI to 2 ms raises these figures to 10,000 packets/s and 8 Mbit/s per direction. These calculations exclude Ethernet/IP/UDP/CIP overhead, interframe gaps and other traffic. Assess full-duplex link utilization separately for each direction, and compare the combined packet workload with the capacity definition in the device's data sheet.

Where does response time accumulate?

End-to-end response includes sensor and input filtering, waiting for an input update, network transit, waiting for the PLC task, program execution, output updates and actuator response. Switch hops, queues and internal device cycles all contribute. Evaluating performance benefits and limitations therefore requires more than measuring a packet's journey across the network.

Example timing budget: If the input RPI, PLC task period and output RPI are each 10 ms, the combined waiting time across three independent periodic stages can approach 30 ms in an idealized model. Network, execution and hardware delays must then be added. This is neither a guaranteed bound nor a formula for every PLC; task priorities and the I/O update architecture change the result.

Jitter is variation in latency or packet arrival intervals. A low average can hide occasional long delays. Assess maximum latency, variation and packet loss together, using acceptance limits set by the process.

What can QoS, multicast management and topology improve?

QoS can prioritize critical traffic during congestion; it cannot create bandwidth or repair an overloaded device. Where multicast is used, IGMP snooping and an active IGMP querier help restrict traffic to relevant ports. For supported one-to-one connections, unicast can reduce unnecessary receiver load. Cell-based VLANs and adequate uplink capacity also help control the scope of traffic.

What should you measure, and where should you start?

During diagnostics and fault finding, first inspect the negotiated link speed, duplex mode, CRC errors and port discards. Then examine PLC/adapter packet rates, connection utilization, task execution times and timeout counters. Use packet analysis tools with a SPAN capture or suitable TAP to inspect packet intervals and sequence numbers. Ping time is not an I/O response measurement. Measuring one-way delay between separate capture points also requires synchronized clocks.

Start with the process's allowable response time, choose the RPI within that budget, and validate operation under normal and peak production loads. Conformance documentation does not replace application capacity calculations. When comparing EtherNet/IP with Modbus TCP, use equivalent data volumes, device loads and end-to-end response criteria.