Taking a closer look at data latency

Following a brief introduction in our August issue, this technical note from Contemporary Controls looks at the performance of repeaters and switches when it comes to time delays

Data latency is the time delay experienced when data is sent from one point to another. A contribution to data latency is the time it takes for an electrical signal to propagate down a wire. Although electricity travels fast, its speed is still finite and over a wire it is slower than in a vacuum. For twisted-pair wiring, it is about 5.5ns/m. Since the same wiring is used to attach a repeating hub or switching hub, this delay is the same for both implementations.

However, the biggest contributor to data latency is the hub itself and the amount of delay depends on if we are using a switch or a repeating hub. One requirement of a repeating hub is to rebuild the preamble in case a frame is received with less than the required number of preamble bits. At 10Mbps, it takes 100ns to send one bit, so the repeating hub must be able to queue at least a few bits worth in case it needs to stuff more preamble bits. The repeating hub does not wait for the full 64 preamble bits to be received before it starts forwarding the frame, but there is a delay nonetheless.

From our own measurements at Contemporary Controls, the delay through a repeating hub can vary from 625 to 840ns. This delay is negligible to the overall performance of the network.

As mentioned before, a repeating hub operates at the physical layer and handles the symbols on the wire. A symbol is the waveshape on the wire that distinguishes a logical 1 from a logical 0. A frame is a collection of symbols representing one transmission unit sent over the wire. An Ethernet frame contains fields beginning with a preamble and ending with a check frame sequence. A valid Ethernet frame must contain all fields including preamble, start of frame, destination address, source address, length, data and frame check sequence. Each field has a fixed length, except for the data field which can vary in length. Since the Ethernet protocol requires a minimum length frame size, the data field cannot be less than 46 bytes. The largest data field can have up to 1500 bytes. Since the other fields are fixed for a total of 18 bytes, the minimum Ethernet frame is 64 bytes and the maximum Ethernet frame is 1518 bytes. The preamble is excluded in this calculation. This information is needed to calculate the delay through a switch before forwarding.

A case in point

For sake of discussion, let us assume we have a two-port switch. Some individuals would call this a bridge. On each side of the switch is a transceiver. Each Ethernet transceiver provides a physical end to an Ethernet wiring segment and the actual end of the network diameter. Therefore, one two-port Ethernet switch links two separate Ethernet networks. Since there is no distinction between one device on one network versus another device on the other network, the two networks function as one larger network. In this case, a switching hub and repeating hub function in a similar manner. However, there is one big difference. A switch port stores the complete frame before it passes it to the other port. It does this because it needs to know the destination of the received frame and to verify that a valid frame was received by observing the frame check sequence. If the frame is invalid, it should be discarded instead of forwarding a faulty frame. Since the switch must store one complete frame before forwarding, the delay in observing the frame on the other port is at a minimum one frame. Since frame sizes can vary, the delay can vary. At 10Mbps and the shortest frame, the delay is 51.2 microseconds, but with the longest frame the delay is 1.21 ms. Is this a problem? Not necessarily.

Assume we are going to send a message consisting of 1000 Ethernet frames, and we were fortunate to be able to send them back-to-back with the minimum inter-frame gap. What would be the data latency due to the switch? The answer is still only one frame's worth. Therefore, by either sending out one frame or 1000 frames, the switch only queues one frame's worth of data under normal conditions. Therefore, it would appear that switch latency is not an issue. But let us study the situation closer.

Let us assume we have one controller functioning as a master and one I/O device functioning as a slave. The slave only responds to requests by the master and never initiates a request itself. Further assume that the two devices are separated by a switch. If the master initiates a one-frame message there will, of course, be a one-frame delay before the slave receives the message. The slave acts upon the request and initiates a one-frame response which also incurs a one-frame delay. Therefore, with a single command/response session, there is a two-frame delay introduced into the process simply by adding a switch. If both frames were long, a total of 2.4ms can be added to the process. Now if we substitute a hub for the switch, we would not suffer the 2.4ms delay, demonstrating that under certain conditions a repeating hub can outperform a switching hub.

Network collisions

But by using a repeating hub, we could potentially introduce collisions on the network that would reduce performance. That is true, but let us study the protocol. Once the master senses a quiet line, it initiates a transmission and then waits for a response from the slave. The only slave to respond was the one polled. The master consumes the response and then initiates another command to another slave. This activity continues with no collisions since collisions are avoided by the rhythmic commands and responses of the master/slave protocol. The most popular industrial protocols such as Modbus and Optomux operate this way.

Now let us change the protocol slightly. Instead of the master making a single command to a slave, it makes multiple commands each to individual slaves without waiting for slave responses. Eventually each slave will act on its command and generate a response. Depending upon the complexity of the command and sophistication of the slave device, responses will begin to occur approximately at the same time and the possibility of collisions increases that will reduce throughput. Will a switch operate better in this situation? A switch will eliminate collisions, but it does not mean it will not drop packets. One of the switch ports connects to the master, and each slave has its own switch port. All the traffic will be directed to the master port owing to the numerous responses, which could flood the output buffer of the port connected to the master. If there is a buffer overrun, then packets will simply be lost.

One way of reducing data latency in a switch is to operate at 100Mbps instead of 10Mbps. This could reduce latency by a factor of 10. Another approach is to use cut-through operation. With cut-through operation, a switch does not wait for receipt of the complete frame before forwarding. A switch only needs to know the destination address before forwarding, and that address is available near the beginning of the frame. Therefore, there is no need to wait for the complete frame to be received. The problem with this approach is that the frame could have a failed frame check sequence (FCS) or it could be a runt frame. These frames should not be forwarded. The runt frame problem can be resolved by waiting a bit longer before forwarding, but the failed FCS problem is not solvable with cut-through operation.

If stations have adequate processing power, operating at 100Mbps should improve network performance. However, the problem at 100Mbps is that the collision domain diameter decreases by about a factor of ten. Using repeating hubs at this speed is not very practical and certainly not very popular because the reduction in network diameter is about 205m. Therefore, the use of switches at 100Mbps instead of repeating hubs is a clear choice.

The original Ethernet technology, operated at half-duplex, is called shared Ethernet. Only one station can transmit at a time. With full-duplex and switch technology, a station can both receive and transmit at the same time over a link segment such as twisted-pair or fibre optics. Since the simultaneous transmitting would normally cause a collision, the collision detection circuitry is disabled, eliminating the collision domain. With no collision domain, the only limit to segment lengths is attenuation of the signal over the segment.

Therefore, in full-duplex mode, a 2km fibre optic segment length, or longer, is possible between two switches operating at 100Mbps whereas it is limited to 412m in half-duplex mode. Full-duplex further simplifies the expansion rules and could improve performance on some networks. However, with traditional master/slave industrial protocols, any performance improvement is unlikely.

Contemporary Controls
m123@industrialnetworking.co.uk