4 ms·

It's fascinating that these latencies are an order of magnitude faster than most 'web services'. Can anyone provide more insight into what is specifically invol

It's fascinating that these latencies are an order of magnitude faster than most 'web services'. Can anyone provide more insight into what is specifically involved in executing a single trade? Are they just enqueueing a trade message in this latency or actually executing the trade? Are they including network latency in these numbers? Also, does anyone have any insights into the hardware and customizations?

lrm242 16y ago
The latencies are typically quoted as round trip through the matching engine. This does not include transit latency to the matching engine but will include any internal transit latency once the matching engine has the order. So you can assume it is from when the order message reaches the network interface on the order processor to when the response leaves the network interface towards the market participant. The amount of work the matching engine has to do is non-trivial but straightforward. Take order, look at type, if market order look for a match on the limit order book, if not handle appropriately (this bit is not included in the latency as it might involve routing to other venues, etc). If it is a limit order it must find the right place to position that order within the order book. Building an order book data structure that is cache friendly and thus very fast is not rocket science but it certainly isn't easy.
- wglb 16y ago
  I agree, but with one exception. I think it is measured from the point of view of a co-located trading firm. So from the time that a trading engine that is a customer of the exchange fires an order to the time it receives either an order acknowledgement (this would result in a resting order) or a fill (completion of a by sell) at the co-located machine is how this would be measured.
Rimpinths 16y ago
I'm a software developer at an exchange in the US. The LSE has not released details of how it is measuring "latency", but FWIW, we measure latency as the time it takes to submit an order and receive an order acknowledgment or fill, with both the sending and receiving outside our firewall. The two biggest SW components involved are the FIX handler (the component used to process orders; FIX is an industry standard protocol) and the matching engine (the component used to match buy and sell orders). I could of course spend hours talking about our hardware and software customizations, but it's a very competitive industry. Our software is C++ running on Linux, and that's about as much detail as I'm willing to go into.
- _grrr 16y ago
  "we measure latency as the time it takes to submit an order and receive an order acknowledgment or fill, with both the sending and receiving outside our firewall." This isn't normally the metric exchanges are referring to when they say 'latency'. They mean the internal processing time, within their network, to process, fill and generate a response to an incoming order. Anything else depends on the individual clients connection, some may be co-located, some may not etc etc... exactly as lrm242 describes.
  - Rimpinths 16y ago
    I thought what lrm242 said and what I said were pretty much the same thing. But there is no standard definition of 'latency', so it's hard to say what "they mean" unless they publish a definition on their website. But I know of at least three major exchanges (one of which I work for) that consider the starting and endpoints for latency measurements to be outside the firewall. As for what Turquoise means, I'm not sure but would love to see their definition to know if their numbers are comparable. Also would like to know if these measurements were made under load because that can also make a significant difference.
- chrisaycock 16y ago
  Right, the only metric I want to see is the roundtrip latency between when I submit my order to when I get my execution report. I just aggregate the timestamps in my FIX logs and usually quote the min, median, max when trying to compare exchanges. Every exchange we negotiate with quotes us their ping-test results. I always have to remind them that there's a lot more to getting an order into the book (especially via FIX) than just TCP.

lrm242 16y ago

The latencies are typically quoted as round trip through the matching engine. This does not include transit latency to the matching engine but will include any internal transit latency once the matching engine has the order. So you can assume it is from when the order message reaches the network interface on the order processor to when the response leaves the network interface towards the market participant. The amount of work the matching engine has to do is non-trivial but straightforward. Take order, look at type, if market order look for a match on the limit order book, if not handle appropriately (this bit is not included in the latency as it might involve routing to other venues, etc). If it is a limit order it must find the right place to position that order within the order book. Building an order book data structure that is cache friendly and thus very fast is not rocket science but it certainly isn't easy.

wglb 16y ago
I agree, but with one exception. I think it is measured from the point of view of a co-located trading firm. So from the time that a trading engine that is a customer of the exchange fires an order to the time it receives either an order acknowledgement (this would result in a resting order) or a fill (completion of a by sell) at the co-located machine is how this would be measured.

Rimpinths 16y ago

I'm a software developer at an exchange in the US. The LSE has not released details of how it is measuring "latency", but FWIW, we measure latency as the time it takes to submit an order and receive an order acknowledgment or fill, with both the sending and receiving outside our firewall. The two biggest SW components involved are the FIX handler (the component used to process orders; FIX is an industry standard protocol) and the matching engine (the component used to match buy and sell orders). I could of course spend hours talking about our hardware and software customizations, but it's a very competitive industry. Our software is C++ running on Linux, and that's about as much detail as I'm willing to go into.

_grrr 16y ago
"we measure latency as the time it takes to submit an order and receive an order acknowledgment or fill, with both the sending and receiving outside our firewall." This isn't normally the metric exchanges are referring to when they say 'latency'. They mean the internal processing time, within their network, to process, fill and generate a response to an incoming order. Anything else depends on the individual clients connection, some may be co-located, some may not etc etc... exactly as lrm242 describes.
- Rimpinths 16y ago
  I thought what lrm242 said and what I said were pretty much the same thing. But there is no standard definition of 'latency', so it's hard to say what "they mean" unless they publish a definition on their website. But I know of at least three major exchanges (one of which I work for) that consider the starting and endpoints for latency measurements to be outside the firewall. As for what Turquoise means, I'm not sure but would love to see their definition to know if their numbers are comparable. Also would like to know if these measurements were made under load because that can also make a significant difference.
chrisaycock 16y ago
Right, the only metric I want to see is the roundtrip latency between when I submit my order to when I get my execution report. I just aggregate the timestamps in my FIX logs and usually quote the min, median, max when trying to compare exchanges. Every exchange we negotiate with quotes us their ping-test results. I always have to remind them that there's a lot more to getting an order into the book (especially via FIX) than just TCP.