The financial services industry thrives on data: millions upon millions of individual buy and sell orders that make up our complex global financial markets. The data has to be accurate, and speed of delivery is a competitive advantage in a business where delivery improvements measured in microseconds can make or break companies.

The financial services industry is a long-time consumer of large-scale HPC, and what’s going on in their compute infrastructure has always been relevant to users on the technical side of HPC. As I was talking to Wombat Financial Services about their new Wombat Data Fabric platform, I caught a glimpse of developing ideas that could influence the future of high performance technical computing (HPTC) as we struggle to deal with systems in excess of 100,000 cores.

Wombat was founded in 1997, and acquired by NYSE/Euronext in March of 2008. The company provides software that allows financial firms access to high speed market data in large volumes very quickly. The volume of financial market data quadrupled in 2007. This growth is continuing in 2008, making the ability to provide rapid access to a growing volume of time sensitive data a key differentiator for competitors in this market.

Wombat’s latest product — Wombat Data Fabric(WDF) — is a middleware solution based on a Remote Direct Memory Access (RDMA) model over an InfiniBand substrate. WDF plugs in underneath Wombat’s widely adopted Middleware Agnostic Messaging API (MAMA) that higher level applications are written to, preventing the need for users to port applications as they move from UDP and TCP to next generation fabric-based messaging.

InfiniBand has several advantages over Ethernet-based data delivery networks in financial services. Because of the volume of relatively short messages that have to be exchanged on financial information networks, demands on the I/O subsystem represent a large part of the capacity challenge in these systems. The context switches and data copies that are needed as data moves from the source system to its destination system using TCP over Ethernet introduce latencies and computational loads that can quickly overwhelm the system, causing delays and leading to missed trading opportunities.

A common messaging architecture in this industry is publish/subscribe, or pub/sub. Pub/sub is a loosely-coupled, flexible messaging paradigm where a set of data sources (the publishers) broadcast information on specific topics, and a set of data consumers (subscribers) receive information on topics of interest to them. The subscribers and publishers needn’t know about one another, and individual subscribers and publishers may come and go as they please without interrupting the operation of the rest of the participants in the data exchange.

As Ken Barnes, VP of Business and Planning at Wombat, explains, “If you go into the datacenter behind any major trading operation (be it Merrill’s equity trading desk, or a stock exchange, or a hedge fund, for example) what you’ll find is a row of cabinets housing hundreds of interconnected nodes. You might have a hundred of them publishing normalized data received from dozens of financial markets they participate in (stock exchanges, derivative exchanges, foreign exchange markets, etc). And you’ll have a hundred(s) of other servers consuming that data to run their trading algorithms and analytical applications.”

InfiniBand allows Wombat’s middleware to facilitate the transfer of data between publishers and subscribers using RDMA, bypassing context switches and data copies in the producing and consuming applications. This bypass reduces load on the computers involved in the exchange and also reduces the time it takes for information to reach its intended application on a particular machine.

Another benefit to this approach shows up when messages are dropped by subscribers. Typically when a subscriber becomes overloaded, or network service is interrupted, messages of interest to the subscriber are dropped. When the subscriber recovers, it has to ask the publisher for a data recap so it can catch up to the current state. This can be problematic for large recaps that can trigger subscriber overloads, dropping recapped messages, requiring additional recaps, and so on. This kind of “recap storm” causes congestion in the network, and can overload the publisher, thus causing problems for other subscribers not involved in the original problem.

Wombat’s Data Fabric exploits RDMA to allow subscribers to get the data they need on-demand by reading it directly from the publisher’s memory. A subscriber that dropped messages can consume the missed messages — at a rate it determines — directly from the publisher with no risk of being overwhelmed by the response and no knock on effect to other subscribers.

Wombat cites performance figures that show its Data Fabric solution running over Voltaire switches can deliver more than 1 million market data messages per second, a five- to ten-fold increase over “current generation” messaging platforms.

All great news for financial markets, but I promised a connection to high performance technical computing, right?

The HPTC community has been spending more time lately thinking about the problem of running large CPU count applications on systems of 100,000 cores and above. A key reason (though not the only one) to build large-scale supercomputers is to run large-scale jobs. But with the current programming models, and relatively immature levels of interrupt survival capabilities provided to applications on today’s supercomputers, it is difficult to see how an application using tens of thousands of processors will ever be able to run long enough to complete as processors drop out during execution.

Why is this? Mostly because message passing is the dominant approach to accomplish parallel work at large scale, and MPI applications are brittle in the face of failures.

Most applications that use MPI rely on processes to use explicit information about the processors with which communication must take place for the computation to advance. If processor X is expecting a message with boundary condition information, then it expects that information from a specific source; when that source disappears, processor X is left waiting. Worse, the entire application usually collapses when a processor fails unexpectedly, and has to be relaunched from the last application checkpoint or from the beginning.

Part of this problem can be addressed by anonymizing participants in an information exchange. If any member of an anonymous communication is taken out of service, the computation can proceed by replacing the failed process with a new process. A pub/sub approach accomplishes this anonymity inherently, and an application could be written to this kind of messaging scheme in our example by having each processor register to provide updates on its boundary conditions on a unique topic ID. Subscribers (processors that need that boundary information to advance the computation) would then listen for those updates and process the data as it arrives, with timestamp data included to account for out-of-order arrival.

This only solves part of the problem: the part where one participant in a communication drops out of the computation unexpectedly, leaving its partners waiting for messages that will never come. It is possible, with sufficient effort, to accomplish this anonymity using MPI, and the dynamic process features in MPI-2 can allow new processors to join the computation to take the place of failed processors.

But what about the dropped processor’s state? When that processor failed, it took with it knowledge that only it had about its portion of the solution to the equations being solved. The application cannot resume computation without this information. And this is where Wombat’s innovation comes in. While common pub/sub middlewares only maintain a two dimensional last value cache, with Wombat Data Fabric each publisher maintains a circular queue for messages published on a particular topic, allowing consumers to read current and past messages on demand, effectively eliminating expensive data recaps and retransmissions in the face of dropped connections as discussed above.

Wombat is taking this a step further in its Data Fabric in that it will expand the API such that this buffer is exposed as a time series, allowing subscribers to move back and forth in time not only to catch up, but also to access arbitrary time series at will, and eventually to do in-fabric analytic processing. This capability, coupled with checkpoints to prevent the message buffers from growing without bound, would allow a new processor to take up a failed process, do a bulk catch up from the last checkpoint that was written, and then catch up with most recent activity by moving through the time series of messages sent to the failed processor. An application written for this kind of approach would probably experience an execution delay as the new process caught up with the computation, but the application would not fail altogether.

Pub/sub messaging in HPC is not a new idea. It’s been explored by researchers in HPC over the past several years. One of the researchers in this area, Professor Geoffrey Fox of Indiana University, points out that pub/sub messaging can offer flexibility and fault tolerance to HPC applications with negligible performance overhead (see for example “On the Creation & Discovery of Topics in Distributed Publish/Subscribe Systems,” Pallickara, Fox, Gadgil. Grid Computing Workshop 2005). But where the rubber meets the road in a system like the one I’ve described above is in the overhead. As Professor Fox points out, “You have to see if the overhead is small enough, and if you can easily make the pub-sub system itself fault tolerant…. All pub/sub systems use queues somewhere, and where they are controls these issues.”

If you are somewhere between the rubber and the road on a project like this, or indeed any project trying to perform useful work on the large CPU-count machines that are headed down the pike, drop me a line at [email protected] and let me know what you’re working on. If I get enough responses I’ll work up a survey article that summarizes current research.