Quantitative Finance Stack Exchange is a question and answer site for finance professionals and academics. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 10 down vote accepted

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.

share|improve this answer
Thanks @Louis. So, this answers how to define latency. Now lets pick up the first metric "Order to Accept". We have a layered architecture so, do you think that tapping at the FIX layer will be the best solution to measure this metric. Can you please explain how it is measured? Is there any tool out of the box that you recommend? Or do you think we should our self save the timestamp when order leaves our system and when the ack/cancel/execution is received in databases and then run reports later. – SmoothCriminel May 7 '12 at 9:50
You just timestamp it on send and receipt. Depending on what resolution you care about you can do this in software or hardware. – Louis Marascio May 7 '12 at 12:53
OK got it. Thanks. – SmoothCriminel May 8 '12 at 21:03

Exchanges provides the following six timestamps:

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

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

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

  4. 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.

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

  6. 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.