Low latency (capital markets)

Low latency is a hot topic within capital markets, where the proliferation of algorithmic trading requires firms to react to market events faster than the competition to increase profitability of trades. For example, when executing arbitrage strategies the opportunity to “arb” the market may only present itself for a few milliseconds before parity is achieved. To demonstrate the value that clients put on latency, a large global investment bank has stated that every millisecond lost results in $100m per annum in lost opportunity [ [http://www.informationweek.com/news/showArticle.jhtml?articleID=199200297 Wall Street's Quest To Process Data At The Speed Of Light] http://www.informationweek.com] .

What is considered “low” is therefore relative but also a self-fulfilling prophecy. Many organisations are using the words “ultra low latency” to describe latencies of under 1 millisecond, but really what is considered low today will no doubt be considered unacceptable in a few years time.

Ultimately the speed of light "c" dictates the limit, a trading engine just 150km (93 miles) down the road from the exchange can never achieve better than 1ms return times to the exchange. This is also assumes a vacuum, in practice there are several routers, switches and cable between the two and even if there was a dedicated cable, messages still travel slower down cable than in a vacuum. As a result most trading engines can be found physically close to the exchanges, some go as far as putting their engines in the same building to further reduce latency.

A crucial factor in determining the latency of a data channel is its throughput. Data rates are increasing exponentially which has a direct relation to the speed in which messages can be processed, and low-latency systems need not only to be able to get a message from A to B as quickly as possible but also to be able to do this for millions of messages per second. See comparison of latency and throughput for a more in-depth discussion.

Where latency occurs

Latency from event to execution

When talking about latency in the context of capital markets consider the round trip between event and trade:
*Event occurs at a particular venue
*Information about that event is placed in a message on the wire
*Message reaches the decision making application
*Application makes a trade decision based upon that event
*Order sent to the trading venue
*Venue executes the order
*Order confirmation sent back to application

We also need to consider how latency is assembled in this chain of events:
*Processing, the time taken to process a message (which could be as simple as a network switch routing a packet)
*Propagation, the time taken for a bit of data to get from A to B (limited by the speed of light)
*Packet size divided by bandwidth, total message size (payload + headers), available bandwidth, number of messages being sent across the link.

There are a series of steps that contribute to the total latency of a trade:

Event occurrence to being on the wire

The systems at a particular venue need to handle events, such as order placement, and get them onto the wire as quickly as possible in order to be competitive within the market place. Some venues offer premium services for clients needing the quickest solutions.

Exchange to Application

This is one of the areas where most delay can be added, due to the distances involved, amount of processing by internal routing engines, hand off between different networks and the sheer amount of data which is being sent, received and processed from various data venues.

*Propagation between the location of the execution venue and the location of the application
*Delays in data aggregation networks such as Reuters IDN
*Propagation within internal networks
*Processing within internal networks
*Processing by internal routing systems
*Bandwidth of extranet and internal networks
*Message packet sizes
*Amount of data being sent and received

Application decision making

This area isn’t really put under the umbrella of “low-latency”, rather it is the ability of the trading firm to take advantage of High Performance Computing technologies to process data quickly. However, it is included for completeness.
*Processing by APIs
*Processing by Applications
*Propagation between internal systems
*Network processing/bandwidth/packet size/propagation between internal systems

ending the order to the venue

Similar to the delays between Exchange and Application, many trades will involve a brokerage firm and the competitiveness of the brokerage firm in many cases is directly related to the performance of their order placement and management systems.
*Processing by internal order management systems
*Processing by Broker systems
*Propagation between Application and Broker
*Propagation between Broken and execution venue

Order execution

The amount of time it takes for the execution venue to process and match the order

Latency Measurement

Terminology

Average Latency

Average latency is the mean average time for a message to be passed from one point to another - the lower the better. Times under 1 millisecond are typical for a market data system.

Latency Jitter

There are many use cases where predictability of latency in message delivery is as, if not more important than a low average latency. This latency predictability is also referred to as Low Latency Jitter and describes a narrow deviation of latencies around the mean latency measurement.

Throughput

Throughput refers to the number of messages being received sent and processed by the system and is usually measured in updates per second. Throughput has a correlation to latency measurements and typically as the message rate increases so do the latency figures. To give an indication of the number of messages we are dealing with the “Options Price Reporting Authority” (OPRA) is predicting peak message rates of 907,000 updates per second (ups) on its network by July 2008 [http://en.wikipedia.org/wiki/Options_Price_Reporting_Authority#Messages_per_Second wikipedia] . This is just a single venue – most firms will be taking updates from several venues.

Testing Procedure Nuances

Timestamping/Clocks

Clock accuracy is paramount when testing the latency between systems. Any discrepancies will give inaccurate results. Many tests involve locating the publishing node and the receiving node on the same machine to ensure the same clock time is being used. This isn’t always possible however, so clocks on different machines need to be kept in sync using some sort of time protocol:
*NTP is limited to milliseconds, so is not accurate enough for today’s low-latency applications
*CDMA time accuracy is in 10s of microseconds. It is US based only. Accuracy is affected by the distance from the transmission source.
*GPS is the most accurate time protocol in terms of synchronisation. It is, however, the most expensive.

Reducing Latency in the Order Chain

Reducing latency in the order chain involves attacking the problem from many angles. Amdahl’s Law, commonly used to calculate performance gains of throwing more CPUs at a problem, can be applied more generally to improving latency – that is, improving a portion of a system which is already fairly inconsequential (with respect to latency) will result in minimal improvement in the overall performance.

ee also

*Latency (engineering)
*Throughput
*Comparison of latency and throughput
*Algorithmic Trading

External links

* [http://www.stuartcheshire.org/rants/Latency.html It's the Latency, Stupid]
* [http://www.hpcwire.com HPC Wire]
* [http://www.low-latency.com/ Low-Latency.Com]

References