Order Management in Nanoseconds

On one hand, if we compete on speed, there will only be one winner in the market. On the other hand, speed only matters if people are competing on the same (or similar) signal. That’s why even if people don’t even know when they are going to need to be fast, they can’t afford to lose the speed advantage.

Technically speaking, FIX protocol is difficult to be optimized for speed. It is simply not designed for low latency trading, in terms of both encoding/decoding protocol and session protocol. However, we can still manage to optimize the FIX based order handling to achieve low latency. After all, the exchange match engine will most likely put the packets it receives earlier to the front of the order book queue.

A good design should achieve not only high performance, but also usability (programming  friendliness) and low maintenance. The design of QWFIX has achieved all those goals without sacrificing any.

The key is the Order Management API (OMS API). It completely hides the low level message encoding/decoding and session management. Application only need to deal with orders (create, cancel or modify) while still enjoying sub-microsecond latency. The framework supports not just the FIX protocol, but virtually any protocol used in any exchange in this world (such as OUCH or ETS).

Another challenge during the design time is the support for multiple exchanges. Each exchange needs special implementations more or less. We managed to make developers feel as comfortable as possible working with QWFIX. In our design, there is only one universal Order class. There are two types of OrderManager class that work together. One type is exchange independent. Another type is exchange dependent that provides exchange specific order handling functionalities.

The OMS API is designed to fit into the entire QWFIX HFT framework. The entire system is not only optimized for latency, but also for throughput as well.

Benchmark:

We used CME NewOrderSingle FIX message to perform the benchmark.

On our 3.33 GHz  Intel Xeon server, we achieved 0.8707 us (870 ns) per message for the following operations combined:

• Create a FIX NewOrderSingle Message
• Set fields in the message
• Booking keeping with OMS API
• Encode message to FIX data stream
• Release the FIX message

Note 0.8707 us is the maximum latency. Because we can use up to two threads per outgoing FIX session, the actual throughput won’t be limited by that latency number if the network is not the bottleneck.

I can further improve the performance if our system’s performance is challenged by any other system.