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.5 ns/meter. 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 10 Mbps, it takes 100 ns 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. Now the repeating hub does not wait for the full 64 preamble bits to be received before it starts forwarding the frame, however, there is a delay. From our own measurements at Contemporary Controls, the delay through a repeating hub can vary from 625 ns to 840 ns. 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 as shown in Figure 3. 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.

Figure 3 — A store-and-forward switch must read in the complete Ethernet frame before forwarding.

Switch Operation

For sake of discussion, let's assume we have a two-port switch. Some people 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 10 Mbps and the shortest frame, the delay is 51.2 µs 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 interframe 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 queue's one frame's worth of data under normal conditions. Therefore, it would appear that switch latency is not an issue. Let us study the situation closer.

Let us assume we have one controller functioning as a master and one input/output (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.4 ms can be added to process. Now if we substitute a hub for the switch, we would not suffer the 2.4 ms delay, demonstrating that under certain conditions a repeating hub can outperform a switching hub.

Now someone might take issue with my example by saying that by using a repeating hub, it 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. Your most popular industrial protocols such as Modbus and Optomux operate this way. Therefore, my example is valid.

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 due 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.