Close and Sometimes a Cigar

The race to the matching engine comprises a few stages. The first covers the outgoing market data’s path from the matching engine to the participant’s network card. This represents the information we want to react on. It seems as if this is completely out of the hand of the participant. However, there are multiple outbound switches (who do not process the outgoing market data update exactly simultaneously), each with multiple ports (which send out data in a round-robin fashion), and each with a separate cable (which are not exactly of identical length). This means that by arbitrating over multiple otherwise identical feed lines one can squeeze out some miniscule latency advantages. The second stage is the only one that is fully deterministic and fully under the control of the participant: the pure reaction time between receiving the market data and sending out any resulting requests. Stage three then is the path from the participant to the matching engine. Here, too, variations in cable lengths and traffic on individual ports and switches introduce slight latency variations under otherwise identical conditions. Similar approaches as for the outbound leg can be used here to squeeze out tiny latency gains.

Figure 1 below shows how the race lead can change over this last stage. It looks at consecutive incoming requests at the outer edge of the exchange’s network. We then analyze if the order of these events is maintained or switched across the order access network. The horizontal axis is the time difference in nanoseconds with which two requests are received. The grey area represents the number of events which maintain the same order whereas the blue area are cases where the event that reaches the exchange first gets to the gateway (and thus matching engine) second. The orange curve is the ratio between the two.

Before discussing the results, two subtle but important details:

1. We compare measured receive timestamps. Due to different factors, these exhibit an uncertainty of a few nanoseconds. This means that two requests which reach the exchange simultaneously could be measured as being received a few nanoseconds apart.
2. These timestamps are only made publicly available for requests that results in changes to the order book. If for example, there is a burst of aggressive orders but only the first one is filled and all subsequent ones miss, then only the first request is included in the analysis. This means that most of these events with very small time differences are (i) passive order inserts, (ii) requests targeting different instruments on the same partition, or (iii) smaller aggressive trades, each one only trading part of the available volume.

Observations:

1. The peak for the total number of events is surprisingly narrow. Over this very short latency range, a lot of requests are received less than 10 ns but very few, say, 20 ns apart.
2. The probability of overtaking drops below 10% for measured time differences exceeding 10 ns.
3. Interestingly, the overtaking probability does not approach zero but levels off at a few percent (extending far beyond the range shown on the plot). At least a few extreme examples (time differences of multiple microseconds) can be interpreted as “background noise”. For example, stemming from requests sent (and timestamped by) a low-frequency gateway.

#eurex #lowlatency #fpga #hft #asic #marketmaking #algotrading #derivativestrading