Traders leap over where the latency is lowest – an introduction to low latency in electronic trading

Low latency and high frequency trading are often mistaken one for another. Both are interrelated. Both involve advanced technology. But they can prioritise competing definitions of performance. Analogies from the quotidian life help to distinguish these concepts. Talking about coffee [1]:

• Deciding to have a coffee and preparing it within less than 5 seconds is akin to low latency.
• After a minute of initial warm up, an expresso machine delivers 20 coffees / minute — that is high frequency.

The next analogy illustrates further the respective features of both concepts…

In computer networking, data is transmitted in chunks (network packets). Just like the thoughtful bus driver, in the previous section, Nagle’s algorithm waits to pack more data before sending a TCP IP network packet. This strategy increases the throughput by avoiding nearly empty packets to being sent over the network. However, this automatically increases the latency.

For that reason, just as the ambulance driver will skip traffic lights, low latency data transfers do not rely on such techniques. Instead, network protocols such as UDP, while less suitable for transfers of huge amount of data, are better at transferring data immediately, thus suitable for low latency.

Both low latency and high frequency businesses focus on speed and benefit from a fast transport of data. But as their priorities diverge, they sometimes adopt competing strategies.

When low latency is a business requirement
As early as 2006, the head of a European investment bank option trading desk formulated the following business requirement:

I want the response time from the algo to the execution to be less than 1 millisecond.

Since then, this maximum latency figure, which was already 200 times faster than a blink of the eye, has been divided by several orders of magnitude. Examples of businesses where low latency is a core requirement feature:

• Trading venues matching engines: Matching buy and sell orders from market participants is a high frequency operation. It also involves low latency, since each market participant must be notified immediately and exactly at the same time. Eurex measured the trigger to target time (informing market participant of a price change) to as little as 10 nanoseconds [2].
• Market makers. Simply put,
  

  Market makers must be as fast as the fastest traders on the venue they are providing liquidity on. [3]

• Low latency hedge fund trading strategies: arbitrage, a simple risk-free trading strategy, can only work if it is possible to take advantage of a price discrepancies before anyone else.

When low latency reduces transaction costs

Not all trading scenarios do require low latency. However, latency has a detrimental impact on most intraday trading:

• The purpose of certain order types might be entirely defeated by latency, for instance, sending a fill or kill order does not work with delayed prices.
• An investor might lose money if a buy order cannot be cancelled immediately in the face of adverse news.
• Overall, latency translates into slippage, which in turn manifests itself in lower revenue over the long term.

When low latency is a nice thing to have

High latency is never a selling point. Low latency is costly to implement. In between, some firms may just want to keep latency under control, without incurring the costs of a delayed execution, nor the investment costs in managing low latency software.

• Standard online coding tests are not suitable for low latency software developers’ recruitment. Online coding tests evaluate performance in terms of algorithmic complexity (aka the Big O notation). However, in low latency trading systems, performance is determined mostly by the memory access time [4], not the CPU computation time. In other words, a low latency software developer may use linear data structures and algorithms, theoretically slower from an algorithmic perspective, but faster in practice because they operate in the fastest areas of the computer memory (e.g. Level 1 cache or even registers). The recruitment process must involve specialised consultancy firms on in-house specialists rather than general purpose recruitment tools.
• Coordination, cooperation and transparency between teams is crucial. Low latency software requires fast and reliable network, is sensitive to operating system upgrades or security patches (when those affect the network stack or communication with the memory) [5], deterministic build systems and specific testing. Infrastructure, QA, development teams must communicate and work together in a timely manner. For instance, operating system security patches, potentially impacting performance, might need to be tested ahead of time, thus causing issues if the application security and system administration team can only roll out changes over the weekend. Aligning priorities and responsibilities across teams is a classic organisational challenge, but it is exacerbated in low latency environments.
• Software development will express unusual requirements. Specific network cards, operating system versions and configuration, hardware, servers reserved to their sole use rather than group wide cloud services… An IT manager in charge of a low latency software team will receive infrastructure requirements that may be difficult to justify, let alone to implement in organisations that favour stability over innovation.
• Special software design techniques. Standard software industry practices, such as poker sizing sessions, intended to obtain work effort estimates, might prove irritating to the IT manager. In effect, low latency developers need to conduct preliminary measurements and tests to validate if an approach is at all possible. Equally, they will come up with software design techniques, such as cache friendly data structures or data orientated design, that may conflict with standard best practices such as encapsulation, object-oriented design.

• Vague client requirements. The absence of agreed terminology creates a lot of confusion. The terms used, such as low latency, ultra-low latency depend on the business context. A trading venue or a market maker views on latency might differ from that of a hedge fund running intraday trading strategies.
• Low latency can be a marketing term. A client expressing an interest in hiring low latency software developers may own a very fast and performant system. But that system may in fact not require any low latency skills at all.
• At what stage of the low latency story are we? Clients running a low latency trading system will express specific and accurate requirements. But in the early stages, some education is required… a hypothetical trading system communicating from the top of the Shard tower in London cannot exchange information in less than 1 microsecond with its ground floor. Nor cannot do it in less than 10 milliseconds if sending information to a New York based trading system. This is due to the fact information cannot travel faster than the speed of light. And this is also why market participants systems are collocated to the exchanges [9].
• A fast-moving business. The timescales introduced in the infographics at the top of this blog, might be soon challenged by professionals pushing technology to the limits. At the time of writing, field-programmable gate arrays (FPGAs) lower latency to range of nanoseconds. This could hardly be achieved by standard computers and software [6]. Application Specific Integrated Circuits (ASIC), such as those used in advanced network switches, process information within picoseconds. ASIC hardware and software development costs, as well as the time to market involved in developing trading systems using ASICS are currently too high to consider this technology. But a creative startup capable of solving those challenges could make trading truly… electronic.

• Know thy hardware (and infrastructure). Low latency trading software relies on cache-friendly data structures [7], or even specialised wide area SIMD registers (an area of research within Data Intellect, more blog posts to come). While a well-designed low latency software trading system can achieve latencies in the range of 1-10 microseconds, latency incurred at every step of the processing adds up. Any misconfigured or suboptimal component in the chain, from network card to operating system configuration can negate the effort spent in designing the software. 
• Low latency programming is minimalistic art. Any superfluous code will add assembly instructions that will add to the latency. 
• Low latency is an experimental science. Rather than continuous integration or delivery, low latency trading involves continuous testing and validation of hypothesis by systematic measurement [8]. Kernel parameters, compilers switches, coding techniques must be tested in a realistic testing environment. 
• Be scientific, not smug. A “Reliable and predictable transport with less than 5 microseconds round trip latency at over 1 million messages per second” must be surely written in language X. Well, not so fast, Aeron – Open-source, low-latency Messaging & Clustering is written in Java. Equally, one would rule out Python for low latency, but projects such as MicroPython – Python for microcontrollers could be leveraged since they compile python code into assembly code executed in a tiny bit of hardware that could be connected to the network.