Is FIX Really Slow?
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.
