By Hugh Adams - (NYSE Technologies - Global Network Architecture) and Gavin McKee (NYSE Technologies - Network Engineer and Head of Latency and Capacity Management)

With the variety of low latency devices deployed in networks from different manufacturers today, it is important to calculate their latency effectively and consistently in the designs produced by Network Architecture. Considering latency without also considering network jitter would not give a complete analysis of the expected network behaviour or its impact on our trading partners.

So what is Network Jitter?

Network Jitter, or more accurately in this case, packet delay variation (PDV), is a measure of the variability for a series of one-way latency measurements. Latency and its partner jitter, depend on the specific design and build of the network topology, the devices used, and the traffic conditions. Latency needs to be treated with the same diligence that traders employ to monitor changing market prices, correlations, and trends. If it is not carefully considered, a network’s performance could undermine the sophistication of the trading algorithms used by its customers. Building infrastructure without understanding the underlying latency and jitter tradeoffs is not an effective design strategy and will lead to poor performance and frequent re-design.

The PDV reveals the variations in latency caused by congestion, route changes, queuing, etc. This metric applies to packet flows between two observation points and highlights network performance consistency. When a network does not introduce any variability, the PDV will approach a value close to zero.

In understanding the factors that contribute to network latency and jitter, and comparing the calculated figures in the designs with the measured figures from testing, it is possible to demonstrate a method for improving the calculated figures, this in turn will improve their correlation and enable us to improve our designs as time goes on.

Factors that Contribute to Latency and Packet Delay Variation (PDV)

As Kevin Gilchrist pointed out in his article, Dialing market data latency monitoring up to 11 - reducing monitoring interference with diagnostics, one of the raisons d’être for latencystats.com is to define the terminology we use when measuring latency. In upcoming blog posts we will explore how we go about testing designs and how this empirical analysis allows us to refine or fine tune network designs or hardware architecture selection in order to reduce latency.

Firstly we need to define the terminology explaining the factors that contribute to latency and PDV, these are:

Signal Propagation Delay

This is the time it takes for signals to travel through a medium such as Fibre optic or copper. The properties of the medium, such as the reflective index of glass or the electron propagation through copper, impose a limit on propagation delay times.

Serialization Delay

This is the time it takes to convert data packets to or from optical/electrical signals on a physical link to values in a dedicated memory buffer. The interface serialization delay depends on the size of transmitted packets and varies with link speed. This delay is equal to the size of the packet divided by the bandwidth. For example on a 1 Gbps NIC (GigE) it takes 10 microseconds to receive a 1,250 Byte (10,000 bits).

Minimum Idle Period

Ethernet devices must allow a minimum period between the transmission of frames; this is known as the Inter-frame Gap (IFG). This interval between frames allows devices to prepare for the reception of the next frame.

Routing and Switching Delay

The routing and switching delays are the time taken to shift packets/frames from an ingress port to an egress port. Depending on the architecture of the platform performing the routing and switching these delays can vary widely. There are two types of switch architecture, store and forward and cut through switching. Store and Forward switches receive the entire frame into their buffers before they begin to transmit it, cut through switches are designed to begin forwarding the frame soon after examining the destination address in the frame header.

Network Processing Delay

These delays are incurred while network elements like switches, routers and firewalls perform more involved packet processing such as filtering, encapsulation, MTU (Maximum Transmission Unit) fragmentation, QOS (Quality of Service), NAT etc. The delay incurred is dependent on the network equipment technology and the specific processing function; more of the functions mentioned here are off loaded to specialized hardware called ASIC thereby speeding them up.

Queuing Delay

Queuing delay occurs in network devices where packets from different ingress ports are destined to the same egress port concurrently. Only one packet can be transmitted at a time from each egress port, the other packets must be queued for sequential transmission. This interface contention is called head-of-line blocking and can lead to substantial latency and PDV.

Multicast Replication Delay

This delay is incurred when handling multicast replication and happens in two stages. The first stage of replication handles the replication from one ingress line card to multiple egress line cards. The second stage handles the leaf replications and is typically accomplished on the egress line card. Again this delay is highly dependent on the switch architecture used; we could dedicate an entire article explaining the process of multicast replication but in the interests of brevity and reader sanity an introduction will suffice.

Latency Terms

Having defined the components that contribute towards the latency in a design; it would also be a good idea to briefly define what we mean when we are referring to latency. To this end here are some simple concepts to consider:

Conclusion

Now that we have defined the terminology for contributors to Latency and PDV, upcoming posts can explore the practical aspects of testing network designs to determine how the design behaves under differing traffic conditions.

The importance of a common latency language cannot be underestimated, as subjective understandings of the contributors outlined in this post would lead to differing viewpoints on network behaviour or results yielded from network design testing.