Low Latency Market Data: Are Proprietary Protocols Needed?

Pantor Engineering's Rolf Andersson examines the data behind the speed of FIX for low latency market data, settling the question of whether FIX is fast enough.

The FIX Protocol as well as software implementing the protocol (aka “FIX engines”) have from time to time been said to have a performance that is too low for use where very high throughput and/or very low latency is required. Performance characteristics of the protocol as well as engine implementations have been discussed in previous articles (Kevin Houston’s article “Is FIX Really Slow?” and John Cameron’s “Evolution of the FIX Engine” Vol 2, Issue 7, September 2008). Granted, there are slow implementations in use and the classic FIX tag=value syntax is too verbose for some use cases: e.g. market data.

Recent developments within FPL such as the release of the FAST Protocol and efforts within the FIX 5.0 usage sub-committee to support alternative recovery state models will enable FIX to be used in high throughput, low latency scenarios. This article reviews the various sources of latency and demonstrates that a FIX over FAST implementation can be used in place of a proprietary protocol to provide very high performance and low latency.

An overview of latency sources

There are a number of latency sources that contribute to the total latency for producing, transferring and consuming market data. The impact of different sources varies widely between implementations. The following sources will be discussed:

• Message processing overhead – the encoding and decoding between transfer format and the internal representation suitable for the processing required in a specific application, as well as safe-storing messages to support recovery of lost messages;
  
• Communication processing overhead – the network processing associated with sending and receiving messages;
  
• Scheduling delay – the delay in reacting on a request to send a message or reacting on a notification that a message has been received.
  
• Transfer delay – the time elapsed between the start and the end of a packet containing one or more messages.
  
• Propagation delay – a function of the physical distance between two communicating parties and the speed of light in the medium used to communicate.
  

These latency sources are to a large extent similar in behavior irrespective of the choice of external protocol, but there are differences as discussed below.

Message processing overhead

The overhead of processing a traditional FIX message is negatively affected by a number of aspects:

• Message content – FIX messages contain a host of information for the benefit of different communicating parties.
  
• Message format – the FIX message format contains redundant information about the message structure. Text is used to represent all data.
  
• Recovery semantics – the FIX recovery mechanism is based on message sequencing per session and a contract that a receiver can re-request messages.
  

Communication processing overhead

The communication overhead depends on the number and size of network packets. Each transferred packet incurs some processing both at the sending and receiving end. One or more messages are transferred in each network packet. Smaller messages mean that less data has to be copied and that more messages can be transferred in each network packet.