Hardware-only vs hybrid vs software-only approaches to handling high data volumes with ultra low latency – Is there a clear winning approach or is the solution dependent on the specific application?
Everybody uses hardware for messaging. The real question is: general-purpose or special-purpose hardware? Even special-purpose hardware starts life as software (e.g. VHDL code) which is compiled to design FPGAs. The software for such machines is generally written and maintained by the vendor of the machines rather than by their owners.
General-purpose hardware typically means an x86 processor running a common operating system with a very rich development environment. Although vendors may have written the operating system – and perhaps the messaging libraries – the key application code the machine executes is generally written by its owner.
Usually, special-purpose hardware is faster than general-purpose hardware, but is more expensive and more difficult to change due to rudimentary development tools. 29West, who licenses messaging libraries that run on general purpose hardware, has watched developments in the world of special-purpose hardware with interest since it potentially could help some of the applications where our products are widely deployed.
One place where special-purpose hardware might make sense is in systems where it can be used for all components of the latency-sensitive messaging path. Imagine if algorithmic trading strategies were implemented in special-purpose hardware machines with no need to use general-purpose hardware at all.
Compared with strategies implemented on general-purpose hardware, such machines would cost more and take longer to develop, but there’s no question that they would have lower latency between the arrival of market data and the placement of an order. We’re not aware of anyone who has built such machines, though, since it appears to be a formidable undertaking.
It’s also clear that performance improves when you replace a software message router process running on general-purpose hardware with a hardware message router (made from special-purpose hardware). But many companies we talk with ask, why not take this idea one step further and use existing general-purpose network routers and switches to do message routing?
Most any infrastructure-grade router or switch built in the last five years has the ability to copy multicast messages at wire-speed. Similarly, they can filter out unwanted messages on different multicast groups. It’s important to note that a growing number of customers are taking advantage of software that runs on inexpensive, general purpose CPU hardware and allows applications to tap the wire speed performance of existing routers and switches.
Are there currently deployments of special hardware in systems driven by market data? We do recognise one task for which special-purpose hardware may be well-suited: that’s the TCP fan out and filtering case. The job of turning a single TCP input stream into several TCP output streams cannot be done by the hardware in today’s switches and routers.
Further, they are incapable of tracking the interests of individual receivers and selectively filtering out uninteresting messages. Software messaging systems can perform these tasks using general-purpose hardware. Special-purpose hardware will be faster, but generally more costly and difficult to change.
We believe that general-purpose CPUs, existing network hardware, and messaging software make the best combination for the vast majority of financial market applications we’ve seen. The only exceptions we know are on networks that cannot support multicast addressing or those where the rich development environments of general-purpose hardware are not required for any component of the system.
What can be proven? It’s easy to see that any message starting in software in one machine and ending in software in another machine while passing though a set of network switches and routers will arrive sooner than one that goes through all of the above plus a hardware message router.
A hardware message router can only add latency when compared to the direct path. Software messaging systems are always faster than a hardware message router in this regard.
