Trading Reimagined is a content series that examines how the transformative power of technology is prompting a reimagining of the markets. Trading Reimagined is sponsored by Exegy.
On Oct. 26, Exegy announced that FIX protocol support is available on nxFramework, a Field Programmable Gate Array (FPGA) -based development framework designed to accelerate time-to-production for ultra-low latency trading systems. The FIX engine was developed to reduce cost and improve server resource consumption for users processing the FIX protocol.
Traders Magazine spoke with Olivier Cousin, Director of FPGA Solutions at Exegy, to learn more.
Briefly discuss your career background and current role / responsibilities at Exegy?
I’ve spent all my career in FPGA, on both sides of the technology. I worked for Intel and AMD, the two main FPGA chip providers, and then in 2010, I left the industry to work for a bank to accelerate a trading platform using FPGA. I started using a young company called Enyx — in fact I was their first customer. I’ve followed them ever since, and then earlier this year, I joined Exegy (which acquired Enyx last year), where I’m the product director for FPGA solutions.
After I left banking in 2013, I went back to Intel, where I developed a library of mathematical models for finance. Later, I did similar work for AMD, while also working on low latency trading platforms.
Let’s talk about FIX protocol support being available on nxFramework. What is the industry background that created a need for this?
To step back, at the beginning of electronic trading, you needed a standard interface for the sell side and buy side to talk to one another, so they came up with the FIX protocol. It made sense to have a readable protocol where you can actually see what’s in the frame that you’re sending. And for the last 30 years, people have used the protocol, because it’s everywhere.
But it is inefficient. Today’s coding and design interfaces are far more efficient than this protocol.
FIX is an ubiquitous standard. Every exchange provides support for the FIX protocol interface. It’s popular because people who aren’t latency-sensitive, and who don’t want to invest time and effort to build something new, can connect to all the exchanges in the world with one interface.
People have been using many different software solutions as FIX decoders, but that presents all sorts of problems. It’s to a point where a large chunk of the CPU cycle is going toward decoding the protocol, which is very inefficient. In terms of scalability and how many sessions you can handle on one core, you have to use multiple CPUs and multiple servers just to handle the traffic. That’s before a single core is used for the actual business logic.
Which leads us to Exegy’s Oct. 26 announcement.
There are two parts to this announcement. The first part is the nxFramework bit, which is to say FPGAs are very hard to use, but the nxFramework takes care of everything you need to start a project. If you have the framework, you don’t have to worry about the complexity of the FPGA, you can just focus on the part that your business is interested in.
The second part is that we are reusing our own framework to start making dedicated products for dedicated applications. Working with a customer, we were asked to accelerate this FIX protocol and put it into hardware, so the CPU side doesn’t have to do all the decoding of that protocol. This means the application is more of an offloading application, rather than a pure latency-sensitive type application.
We are taking the piece of code that everybody has to go through to decode the market, where every single server in the cycle is doing the same thing over and over again, and we are pushing it onto the hardware. You don’t have to do the decoding in the software – it’s handled very efficiently on the hardware side.
So really, the trick here is to use the power of the hardware to transcode, or reform the information, so it’s a lot easier for the software side to use. That’s a big advantage.
Another advantage is that while the information is in the FPGA, you can change the information on the fly. There are a lot of applications out there where you have to transcode – meaning you have to change part of the information, and then resend it. With the FPGA, you can do that directly in the card and send it back without having the software be involved at all. This continues to free up valuable software resources for the user’s core logic.
Those are the two ways the platform is accelerated. But essentially, it’s an offload – you can manage a lot more sessions, you can manage a lot more of that protocol on one server, whereas before you would need multiple servers.
Of the range of institutional market participants, i.e. trading and investing firms, who is this most relevant for?
The highest-frequency traders are all working with a dedicated, binary protocol that very efficiently picks up the information they need, sends the order out, and they’re done.
The FIX protocol is different. It’s for traders that don’t have a different decoder for every exchange, and they use the generic protocol. So again, it’s not just a low-latency gain, it’s an offload gain.
For example, if you are an exchange and you have to manage thousands of sessions, you would have to have a fair amount of servers to do that protocol decoding. Whereas now you can just plug in the card and you can have hundreds of sessions running in parallel.
And because it’s done in hardware, you don’t have a problem managing the flow of this information or having buffering. You have all the benefits from the FPGA – you have the acceleration plus the deterministic way of working, and you’re not missing packets and you’re not missing information. This is all very, very important for an exchange.
Also, internally in a bank or prime brokerage, when two systems need to talk to one another, most of the time they use FIX because it’s easy, it’s always available, and there’s always a decoder somewhere. But with this acceleration, you could save on the number of servers and the number of CPU calls to manage the transfer of data. This is about being resource efficient for something that previously was not.
What else is interesting that people should know?
While we have a very strong background on the hardware side, I would say about 80% of customers who are interested in this will be software people. You absolutely do not need to be a hardware person in order to use this; the product is in hardware, but it’s configurable by software. We have a very flexible implementation where the software can configure the hardware to pick up the data that you want to pick up.
You’re not buying an exotic piece of hardware here. It’s a clever network card that can decode your FIX protocol – you’ll still have that interaction in the software to pick up the right data and to configure it on the fly.
How would you sum up the advantages of the product?
It’s an offload, mainly. You’re freeing up your CPU and you’re freeing up your server. Instead of having to buy yet another box because the box doesn’t handle that many sessions, you have just one server that can handle hundreds of sessions per card.
So it’s all about offloading the process that doesn’t need to be on the CPU onto the hardware, so you can do more with less basically. Many of our customers who aren’t the lowest-latency traders are very cost sensitive, and if there’s a solution out there that can do a lot more than their current server, they’ll be very interested in that.
