About a-team Marketing Services
The knowledge platform for the financial technology industry
The knowledge platform for the financial technology industry

A-Team Insight Blogs

Messaging Platforms and Hardware Choices: General Purpose or Accelerated?

Subscribe to our newsletter

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.

Subscribe to our newsletter

Related content

WEBINAR

Recorded Webinar: Re-architecting the trading platform for interoperability, resilience and profitability

Trading platforms have come a long way since the days of exchanging paper certificates and shouting across trading floors, pits and desks in the early 2000s, but there is progress still to be made as firms strive to reduce risk, increase profitability, and make their mark in digital assets trading. This webinar will review the...

BLOG

BMLL and CCData Partner to Offer Data Across Traditional and Digital Asset Markets

BMLL Technologies, a provider of Level 3 historical data and analytics, has made a strategic partnership with CCData, an FCA-authorised benchmark administrator and provider of digital asset data solutions and settlement indices, to offer clients access to data and metrics across both traditional and digital asset markets. The partnership is a response to growing demand...

EVENT

RegTech Summit London

Now in its 8th year, the RegTech Summit in London will bring together the RegTech ecosystem to explore how the European capital markets financial industry can leverage technology to drive innovation, cut costs and support regulatory change.

GUIDE

Regulation and Risk as Data Management Drivers

A-Team Group recently held a webinar on the topic of Regulation and Risk as Data Management Drivers. Fill in the form to get immediate access to the accompanying Special Report. Alongside death and taxes, perhaps the only other certainty in life is that regulation of the financial markets will increase in future years. How do...