Is FIX Really Slow?

By Kevin Houston
Working on a Porsche analogy: To say that all Porsches are slow is, clearly, about as ridiculous as saying that FIX is slow! Kevin Houston explains.
All early Porsches have their roots in the design of the Volkswagen Beetle designed by Ferry Porsche’s father Ferdinand. The VW Beetle is only capable of about 80 mph and even that would be at the cost of a terrified driver. Early Porsches share a lot of their design elements with the Volkswagen, however that does not mean that Porsches’ are slow. Many of us will have been on track days where we have driven Porsches around a race track, hitting speeds of well over 80 mph, without inducing any great feelings of fear.
The early FIX engines, designed in an era of simply routing care orders between the buy-side and sales traders, are also slow and if used for modern high speed trading would result in traders nervously guessing whether each message would be one of the lucky ones that went through quickly or, more probably, one of the unlucky ones that took several seconds to arrive at its destination. Again some of us can testify that these early engine do not represent the state of the art; equally, however high velocity trading houses, today, are using FIX to trade in around 250 microseconds and a small number of FIX engine vendors are currently capable of consistently beating 10 microseconds for message processing, delivering throughput of around 100,000 messages per second.
To say that all Porsches are slow is, clearly, about as ridiculous as saying that FIX is slow. The remainder of this article examines the second myth in more detail.
First a bit of History
FIX started as a pilot between Salomon Brothers and Fidelity Investment to automate the placement of orders, the reports of executions and the distribution of advertisements and IOIs. Indeed many early FIX implementations did not even place the order electronically, but only reported the executions after order placement. At this time there was only one FIX engine on the market place and the price was extremely high, with the performance, by today’s standards, being extremely low. FIX adoption was driven by error reduction and the like. The arrival of the early commercial FIX engines did the community a great service by creating cheaper alternatives; but the performance bar was not very high. Often when people now refer to FIX as being slow, they are using the yard stick of early FIX engine performance as the measure. Since then and particularly over the last 5 to 10 years, increasing emphasis has been placed on the performance of FIX driven by a number of trends, and the FIX engine vendor community has responded. Some have accepted their current performance levels as adequate for order routing but not DMA and focused on that market; others, often new entrants, have engineered FIX engines from the ground up, to focus on future-proofing performance.
The drivers behind this need for speed are worth noting:
• Increased market data
• Increased order volume
• Exchange adoption of FIX
• Large percentage of trades going electronic
• Rise and rise of algorithmic trading
These drivers lead to two separate performance needs, high throughput and low latency. Whilst these are related needs there are optimisations that can be made that favour either. For example, FIX communicates over TCP/IP, typically a FIX message uses a few hundred bytes, but an IP packet has space for around 1,400 bytes of information. A setting on the IP communication layer allows you to select whether packets should be held back to wait for additional information that can be sent in the same packet.
This obviously improves throughput as the receiving application has to process fewer packets, but it has the potential drawback that it increases latency for at least the first message by it having to wait for subsequent messages. So, whether you allow this hold-back or not depends on your performance needs, or profile. This process was first introduced by John Nagel and is named after him; see http://en.wikipedia.org/wiki/Nagle’s_algorithm for more details. OK, so FIX can be fast but a lot of the implementations out there are dated and therefore can be slow; so, are there other things FPL is working on that will help with performance?
Where are we today, how long does it take?
Let’s take a look at some of the time costs in sending a FIX message. Obviously this is a very rough estimate and there are a lot of variables, but here are some general timing that are worth covering. Firstly, there is constructing the message, which typically takes something like 10 microseconds, saving a copy before sending, 50 microseconds; sending it to the wire, typically 10 microseconds; transmission time, a function of distance but easily worked out as distance divided by 2/3 the speed of light; switching time, a function of the number of routers and switches and their ilk, via the operating system into the user space, say 10 microseconds; and finally parsing in user space 10 microseconds. There are a number of ways you can improve these such as saving the copy of the message asynchronously, etc., but that still leaves a lot of time spent building the FIX message and it’s tag = value syntax.
What is the FPL Global Technical Commitee Committee doing to make things even better?
Whilst FIX can be as fast or faster than most of today’s exchange API’s there are a number of areas that the FPL GTC is working on and has approved Working Groups to look at these issues.

1) Putting FIX on a par with Native Exchange API’s – Stateless FIX
A lot of exchanges want to implement FIX in parallel to an existing interface. This means that they have a matching engine that stores its state and an interface that does not. If they architect their FIX interface to talk directly to the matching engine then the main difference between the FIX interface and the native interface is that the FIX interface has a costly extra persistence operation. This means that at best the FIX interface is going to be something like 50 microseconds slower than the native exchange interface.

FPL recognised this problem and introduced a partial solution, for non-trading messages in FIX5.0, the GTC has now prioritised extending this solution to include trading messages and makes more extensive use of the Application Sequencing messages introduced in this version.
2) Examining how much information we move?
FIX has historically been designed to meet the needs of many distinct constituents. One of the repercussions of this has been that some fields are marked as mandatory when in fact they are only required for a certain subset of the FIX community. FPL has decided to revisit what constitutes a mandatory field within the specification. For example, does there need to be 7 mandatory elements in the Order Cancel Request message, when all an exchange may need is the Order ID to be able to cancel the order?
3) Optimised transports for FIX – Binary FIX
Currently a major cost for a FIX interface is the time it takes to serialise a FIX message into a Tag=Value format. This Tag = Value string is simply a version of a piece of memory in the senders computer that is used to create a copy of the memory in the receivers computer. FPL introduced the repository some time ago and many firms already use this to describe the piece of memory to their computer programs by generating object models directly from it. Why not take this one stage further and also convert these object models (or pieces of memory) into information exchanged on networks using some of the lessons learnt from the FIX Adapted for STreaming (FAST) initiative? Then examine this structure and optimise it?
4) FIX Interparty Latency – FIPL
Whilst we are focusing on latency and performance of FIX engines in this article; what we as an industry are concerned about is the end-to-end latency across the whole trading infrastructure. One of the first things you need to do in any engineering endeavour that aims to improve the performance of a system is measure the performance of that system and identify where the largest performance problems are and where the easiest gains can be made. Many organisations have detailed network level information on the arrival and departure of network packets, many components of the trading system write log files that detail when they receive a message and when they forwarded it on, and sometimes even information to trace its path through their element of its overall journey.
However when you try to assemble an end- to- end picture of the journey of a trade across an organisation and through many systems that entails, you find that often this information is stored in different formats and compiled on a different basis from system to system. The FIX Interparty Latency Working Group is aiming to develop a standard that will allow the easy assembly of this information on a consistent basis across multiple organisations so that we can understand the latency introduced across the whole of the trading life cycle.
So why is FIX perceived to be slow? Because some implementations of FIX are slow and those implementations are slow because the industry didn’t need them to be fast! Now that people are demanding faster FIX interfaces the community is providing them. Similarly the Volkswagen was slow because the peoples’ car was targeted at simply moving people around, as an economy car, not moving them quickly.
Road-going Porsches are faster because they are optimised for a different problem, going quickly on public roads. Now we are entering the era when we are racing on a circuit and unless your car is designed for that you are going not to make it to the starting grid.
FIX is the same, the engines designed a decade ago to do one job cannot be expected to lead the field when asked to perform an almost entirely different one.