Defining and Measuring Trading-System Latency

# HFT - How to define and measure latency?


# HFT - How to define and measure latency?












I have read and heard a lot about latency. But I can't find any solid information that explains how latency is defined and measured. When people say they have achieved millisecond or nanosecond latency, which two points is that between? And what methods are used to measure it?

We are going to deploy one strategy in a colocated server and I have been given a task to report latency. I need assistance in defining and measuring latency.

## Answer by Louis Marascio (score 13, accepted)

https://quant.stackexchange.com/a/3447

There are typically two important metrics:

Order to Accept. This measures the round-trip time it takes your application to send an order to the exchange and get an accept, cancel, or execute back. Think of it as the minimum amount of time required for you to ask the market to do something and know whether it's been done. This plays an important role when building execution logic in models.

Order to Feed. This measures the amount of time it takes for an order or action to be represented in the venue's multicast depth of book feed. Depending on venue and other factors this can be faster than Order to Accept.

Other measures of latency can always be conjured. Some folks consider Model Latency, or the amount of time it takes a model to receive a piece of data, perform some calculation, and act upon it. Most numbers you see people discussing and passing around are worthless because you have no frame of reference as to what exactly they mean.

Remember, latencies are almost always relative. For example, the above metrics will of course be impacted by your specific co-location situation relative to the venue. That means your Order to Accept measure will be different from someone else's unless they are co-located in the same place as you (which is not uncommon, of course).

Underlying all of this is transit latency that the network imposes. As you can imagine the move towards co-location was driven by the fact that eliminating transit latency was quite easy by increasing proximity to the matching engine. I don't consider transit latency to really be a first-order metric for a trading system since it is built into the important domain specific metrics like I described above. However, it's always measured to ensure the critical network paths are behaving properly.

## Answer by shoonya (score 4)

https://quant.stackexchange.com/a/19491

Exchanges provides the following six timestamps:

- Gateway In Timestamp-T1. Time at which the order was received by the Gateway from the members TCP connection.

- Gateway Out Timestamp-T2. This is the time when the order was dispatched by the Gateway to the Matching engine.

- Matcher In Timestamp-T3. This is the time the order was received by the Matching engine.

- Matcher Out Timestamp-T4. This is the time the response leaves the Matching engine. This response could be an order confirmation or an immediate execution or both.

- Gateway In Timestamp-Response-T5. This is the time the gateway receives the response from the Matching engine.

- Gateway Out Timestamp-Response-T6. This is the time the gateway dispatches the response to the Members TCP connection.

The RTT(Round trip time) is T6-T1. All timestamps are in Nano seconds. This enables the member to accurately calculate the time spent in each leg of the journey for an order.