How low can you go? Pontus Networks case study shows how latency can be reduced 20 x

The technological arms race which has existed among infrastructure providers in order to reduce latency of execution among FX firms continues to increase, as the will to compete from within trading desks globally against other participants by using high speed execution systems has not declined, regardless of the regulatory purging that has taken place in certain regions.

To demonstrate this further, Pontus Networks, a technology consultancy which provides services to financial institutions on how to maximize their environment by achieving low latency, has conducted a case study which details the methodology required to reduce latency by up to 20 times.

According to Pontus Networks, the firm has recently helped an investment bank benchmark and improve the latency of an FX pricing system without changing a single line of code or any of the target hardware. We reduced the pricing system’s peak latency of receiving a raw market data tick to sending a FIX market data snapshot to 25 clients by over 20 times by combining three components, namely PontusVision which manages the application threads, RedHat’s Realtime operating system (MRG), and Californian software provider Azul Systems’ Zing Java virtual machine.

The study conducted by Pontus Networks concluded that market makers on the sell-side have to send prices to their customers within 1 millisecond of a new price in order to retain market share.

Unlike the fast-paced world of equities, some of the primary FX markets tick at relatively low frequencies of updates once around 100ms or more. Within that period, the first 5ms is where the majority (around 90%) of the trades occur. Some of the markets will also batch and randomize orders in 1 millisecond buckets, with any orders received in the 1st ms randomized, followed by any orders received in the 2nd millisecond, and so on.

Any serious market maker has to be able to reliably send out quotes to clients ideally within the first 1ms; otherwise, they miss a large number of orders due to high spreads, or worse, risk having stale prices and lose money.

The main goals of the exercise were to test and improve end to end latency on an FX trading system without changing a single line of code. The latency was measured by matching raw market data ticks with FIX market data snapshots sent to 25 FIX clients using a network switch with a high-precision clock.

Pontus Networks finds that the majority of non-real-time operating systems (OSs) are not very good at allocating threads for latency-sensitive applications. Modern OSs are typically configured to balance the load across various CPUs rather than reduce the latency of the application. When dealing with latency-sensitive applications, these strategies cause the latency to increase significantly.


(Source: Pontus Networks)

The conclusion of the case study shows results from the six tests performed, with the most predictable system behavior having happened in test PV-006 (displayed in the above graph), with peak latencies that were over 20 times lower than test case PV-001. Zing was the clear winner of the JVMs, and MRG was the most predictable OS; however, the predictability comes at a cost of around 20% higher average latency than when using the plain RHEL 6.4 kernel. Lastly, the PontusVision Thread Management module also significantly helped improve performance in all cases.

Read Also: