Identifying Trends in Low-Latency Systems

Read more on market volumes and low-latency requirements, demand for ‘commodity’ low-latency solutions and Integrated low-latency solutions.

Market volumes and low-latency requirements
While overall traded market volumes have been depressed in recent months, the volume of order-book related market data has remained relatively stable – reflecting the long-term upward trend in update rates. A contributing factor, in European equity markets at least, is the growing number and market shares of the new MTFs (Chi-X, Turquoise, BATS etc.). Most MTF traffic is generated by black box trading systems: smart routers, liquidity seeking algorithms (algos) and other automated trading systems. These generate a particularly high level of order book updates: orders are being constantly placed, removed and updated, so naturally when compared to the traditional execution venues these markets contain a much higher proportion of order book updates to executions.

A further characteristic of automated trading systems is that they break larger orders down into a series of smaller orders, so while total trading volumes may remain constant or decline, the number of trades can continue to grow rapidly. The volatility resulting from turbulent market conditions has also been instrumental in maintaining order book activity, with random and frequent spikes in volumes being observed.

So while trading volumes may continue to decline in the foreseeable future, the overall volume of market data messages will be maintained or may even grow. Trading systems will have to be scaled in consequence, and must be capable of handling both the market data throughput and ensuring that the low latency required by automated trading systems is fully respected. And continuing market volatility will also dictate that trading systems should be sufficiently dimensioned to handle shorts bursts of high market activity with no degradation of latency, and to degrade ‘gracefully’ if such bursts persist over longer periods.

The demand for ‘commodity’ low-latency solutions
The profusion of execution venues on both sides of the Atlantic, and the associated rise in automated trading, mean that today low latency is no longer the exclusive domain of arbitrage specialists, hedge funds, and market makers, but is a pre-requisite of any advanced trading system.

We see a distinct move towards the commodization of low-latency solutions. The costs of specialized low-latency components (real-time OS, specialized switches, dedicated FGPA cards etc.) are probably justified in specialized environments where sub-microsecond (ultra-low) latency is required, but there is also a much broader need for cost-effective l0w-latency solutions built around commodity hardware and software. Platform vendors’ latest releases have registered good progress towards this goal: we are now shipping versions of SunGard’s trading software based on commodity OSs (Linux 2.6, Solaris 2.10), connected via 100Mb Ethernet, that are capable of delivering 99.999% sub-millisecond latency (i.e. only 1 in 100,000 messages has latency above 1 ms.).

A commodity low-latency system reduces considerably the cost of ownership, which can then be driven down further by ensuring that the software is fully self-contained. High-performance integrated databases and middleware can ensure that there are no dependent products or third-party licences to administer.

A major limiting factor, as regards the pace with which commoditization is likely to progress, is that developing low-latency time-sensitive software on commodity operating systems requires a high level of expertise and can be laborious. It needs highly trained and experienced R&D teams with precise knowledge of OS-specific mechanisms such as high-precision timers, kernel pre-empting and scheduling techniques. And the constraints of low latency must be satisfied without significantly compromising the performance of throughput-orientated applications.

Integrated low-latency solutions
It is also important to keep in mind the big picture of the overall trading architecture, covering market data capture, decision making, and order routing. Low latency must of course be maintained throughout this workflow in order to realise value from the associated investment. A software architecture that is well integrated across the workflow is likely to be a key element in ensuring that this is achieved, and can also help to drive down cost of ownership.

When the market data capture, decision making and order routing processes are all handled via a set of tightly coupled applications, it is possible to avoid a whole class of latency traps such as protocol conversion, inter-application queuing, middleware overheads, and inefficient communication stacks. It is of course difficult to realise such integration fully in fast-moving multi-asset trading operations, but this must be the goal for trading firms and ISVs. This is a key priority driving our work at SunGard.