Low-Latency.com

Low-Latency Delivery Enters Mainstream; But Standard Measurement Remains Elusive

By Andrew Delaney, Editor-in-Chief, A-Team Group

Low-latency distribution of market data via direct exchange feeds appears to have hit its stride. In fact, it has become the latest arms race. The fact remains, however, that there is no standard measurement of market data latency that offers apples-to-apples comparison between competitive data feeds, feed handlers and databases.

The institutional user community, meanwhile, seems to be embracing the concept of superfast data delivery – via direct feeds, consolidated vendor feeds, or both – increasingly seeing it as a must-have in certain asset-based markets if they are to retain any hope of maintaining competitiveness.In short, low-latency has become the latest arms race – and a two-sided one. Data consumers ‘need’ low latency to stay ahead of the pack, transact trades before the market moves against them, and cope with the high volumes of trades that result from the slicing and dicing effect of algorithmic trading. And exchanges now ‘need’ low-latency delivery to remain competitive with alternative trading venues, keep institutional users seeking alpha happy, and to generate new revenue streams in the face of declining returns from other areas of their business.

At Interactive Data’s recent seminar in London – The New World of Market Data: Data Latency and the Consolidated vs. Direct Debate – a poll of the audience of about 100 found that 61% used direct exchange feeds, with 94% stating a need for both direct and consolidated feeds.

Key drivers for the use of direct feeds identified by the panelists were, oddly, reliability (if a single direct feed goes down, firms can continue to trade on other markets, whereas consolidated feed downtime hits across the board) as well as the usual fear of being last to know and therefore out of the market.

So low latency data delivery delivers the marketplace a win-win-win, with the third ‘win’ enjoyed by the ever-increasing horde of data feed, feed handling software and high-performance database vendors that help the exchanges and the institutions assuage their endless thirst for faster, ever-faster data.

The fact remains, however, that there is no standard measurement of market data latency that offers apples-to-apples comparison between competitive data feeds, feed handlers and databases. As a result, those seeking to build low latency data infrastructures in support of algorithmic and other electronic trading applications face an increasingly bewildering array of statistics from a slew of competitive suppliers, each showing how its particular product is superior to its rivals’.

Moreover, current thinking on the institutional side of the marketplace appears to sweep under the carpet all thought of what such an infrastructure might really cost. This is in part due to internal allocation of budgets, where it’s often unclear which department carries the burden of paying for a new-fangled low latency delivery platform. And it’s partly due to the ‘whatever it takes’ mentality characteristic of the current phase of the investment cycle: namely, we’re making money so who’s counting?

All of this, of course, makes measuring return on investment impossible. Without getting into too fine detail, it’s tough to demonstrate the business case for a given technology infrastructure without understanding the true benefits from fast access to markets, who is responsible for the cost of ownership and future maintenance, and the true opportunity cost of spending just a little bit more cash on just a little bit faster infrastructure.

So, in short again: we all seem to acknowledge that low-latency market data offers a true benefit to the marketplace, but none of us really seems to know why, beyond the obvious platitudes.

Take, for example, the various vendor claims about the latency imposed by their respective systems. Illustrative claims – from key players’ web-sites or from our own coverage – include a system that “boasts throughput a million messages per second at sub-millisecond update rates”; an off-the-shelf real-time database that “achieves stream input rates exceeding 1,000,000 messages/second”; and a platform that “under message rates exceeding 100,000 per second …can produce results in as little as a fraction of a millisecond.”

It’s questionable how useful this information is to decision-makers tasked with figuring out how best to spend budget on a high-performance data infrastructure. As with any kind of benchmarking, the absence of a truly transparent and standard methodology for measuring travel speeds through the mix of networks and applications that constitute an electronic trading system, statistics like this can be unhelpful.

Happily, market practitioners are taking the challenge of latency measurement seriously. Reuters, for example, recently hosted a seminar in which it outlined key parameters for measuring the latency of market data delivery systems, drawing on a position paper: Measuring Low Latency Characteristics of Direct Exchange Feeds.

At the briefing, Mike Powell, global head of Reuters real-time enterprise information, and Scott Kennedy, business manager, Reuters Data Feed Direct, Europe and Asia, gave a broad overview of the rise and rise of direct exchange feeds, and offered up some interesting facts around delivery times.

They said, for example, that in considering the communications infrastructure requirements for a high-speed data delivery system, it’s worth considering that a 512 kilobyte data packet will add two milliseconds of latency when delivered over a two megabit line, with that latency dropping to 0.41 milliseconds over a 10 MB line and to 0.041 milliseconds over a 100 MB line.

They also pointed out that an order message directed to the London Stock Exchange from a client in New York would take 84 milliseconds roundtrip on a typical telco line, 18 milliseconds roundtrip from Frankfurt and 208 milliseconds roundtrip from Tokyo. Using so-called proximity services increasingly offered by major exchanges can reduce the turnaround time to two milliseconds.

Powell and Kennedy said latency was mostly added by two key components of any market data delivery infrastructure: the communications line and the computer processing set-up. For the former, key factors for reducing latency, they said, include serialization of data, distance considerations, the number of hops involved and how to handle queueing. For the latter, processing power, device configuration, operating system platform and application software architecture, are all key considerations.

The position paper describes Reuters’ approach to measuring and comparing the latency of direct exchange feeds, and offers up best practices recommendations for comparison. High on the list: “If a firewall exists between the consuming application and the direct exchange feed systems, ensure that all traffic from both direct feed systems is flowing through exactly the same physical firewall with exactly equivalent firewall configuration settings. For best comparison results, eliminate the firewall from the testing configuration when possible.”

“For UDP-based feeds, use the same physical lines to feed both direct feed systems that are to be compared. For TCP-based feeds, run a set of tests where the two feeds (one feeding each system) are swapped for half the test so that if there is a latency difference between the two raw feeds, that difference is spread fairly between the two systems.”

Meanwhile, in a separate white paper currently under development, Wombat Financial Software acknowledges the impact of the U.S.’s Regulation NMS on firms’ hunger for low-latency infrastructures and addresses the Securities & Exchange Commission’s requirement for firms to “implement reasonable steps to monitor such latencies on a continuing basis and take appropriate steps to address a problem immediately should one develop.”

Wombat says Reg NMS compliance “requires the measurement of latency inherent in any relevant market data from ‘end to end’ (the quote origination point through to the ultimate consumption point) – in real time. Market data systems must be able to capture quote and trade-level timestamps, adding transparency at each point in the market data system through which such data passes – in the feed handlers, the consuming applications and any distribution points that may lie in between.”

Wombat also points out that systems will be required to “accommodate substantial latency changes dynamically to minimize any impact upon best execution provision.” Such systems, it says, must “withstand and recover from outages at any single level, and moreover the occurrence of multiple simultaneous component outages, with minimal impact.”

The company, which specializes in feed handlers for direct exchange feeds but also offers adaptors for consolidated feed services, has embedded a number of capabilities into its platform to meet these criteria.

They include: its Latency Monitor system, for assessing latency at various points in a series of distributed nodes; its PAPA Stats facility, which publishes higher-level information from feed handler sources (including total messages in/out, bytes in/out, CPU statistics, memory statistics and subscriptions); and its Network Monitor, which monitorseach connection across the entire delivery infrastructure.

Others, meanwhile, are working to provide independent tools for taking a close look at latency. Perhaps the most ambitious of these is Peter Lankford’s Technology Business Development Corp., which has begun offering benchmarks of market data platforms that it offers to qualified institutional users.

Over the past six months or so, Lankford and his team conducted a number of benchmark tests of the Reuters Market Data System, running with a variety of HP hardware and chip options: on an HP ProLiant DL380 Server with two 3.0GHz Dual-Core Intel Xeon 5160 processors; on an HP ProLiant DL385, with two 2.8GHz single core AMD Opteron processors; and on HP Proliant Servers with Multicore AMD Opteron Processors.

In the first of these tests, TBD Corp. achieved one million updates per second end-to-end through a single RMDS server, using data updates from market data vendors, interdealer brokers and institution internal data. The test achieved end to-end infrastructure latency of less than one millisecond at up to 350,000 updates per second.