Low-latency data feed and execution APIs

Again, quite vague especially when you look at the other more recent press-release:

http://www.enyx.fr/2013/06/accelize...rated-platform-for-ultra-low-latency-trading/

This is just latency measured from and to a network card via the FGPA and not round trip to exchange and back. The 3 microsecond latency refers to internal wire-to-wire, ie receipt of market feed packets, FGPA decoding, some trade logic calculations on the FGPA board (potentially CPU) and back onto the wire. I am not arguing against latencies way below 1 millisecond there. In fact if you believe the results of this paper, below 1us is doable

http://algo-logic.com/~jwlockwd/publications/Low_Latency_Library_for_HFT-Algo-Logic-4831a009.pdf

 

And this?

http://www.waterstechnology.com/ins...2215166/cme-upgrade-targets-latency-variation

"CME Upgrade Targets Latency Variation
Author: Max Bowie
Source: Inside Market Data | 10 Oct 2012
Categories: Exchange Data | Latency
Topics: dataIMD2012Oct8CME GROUPLatency
Send Print Share Comment Send to Kindle
CME Group is rolling out a new infrastructure and order gateways, dubbed CME Globex Performance Release, to increase traders’ confidence in trade execution by reducing the variability and unpredictability of latency figures between order handling and publication of trade data.
The exchange will migrate products from its legacy infrastructure to the new release over the course of seven weekends—a process that started at the end of August with its core trading engines, which were completely switched over on the weekend of Oct. 6, ahead of an early adopter process for all interested parties—before migrating all FIX sessions to the new infrastructure on Oct. 13.

“For us, the problem was the tail. So we are working to eliminate that and make sure that we can deliver the same latency under all market conditions” —Ari Studnitzer, managing director of enterprise architecture, CME

“One of the big things we are targeting is around non-implied market data [such as CME’s equities and currency futures markets], to ensure that order entry and market data delivery are within the same millisecond 99 percent of the time, so that if you are participating in a fill event, you will get the fill and the trade data about that fill within the same millisecond, as it is critical to be able to deliver both at the same time,” says Ari Studnitzer, managing director of enterprise architecture at CME. “For us, the problem was the tail. So we are working to eliminate that and make sure that we can deliver the same latency under all market conditions…. If it takes a second to print trade data, there is no point in having order entry latency of 10 microseconds.”
Studnitzer says the effort is not primarily intended to reduce overall latency—though this can be a beneficial side effect of the initiative—but rather to reduce the variance of latency with which different types of transactions occur in the exchange’s systems. “Latency is not the goal; it’s the outcome. We measure variability between the median and the 99th percentile of latency. So, for example, we’ve been able to reduce the delta to around 100 microseconds for market data dissemination, whereas that was previously measured in multiple milliseconds,” he says. “The goal of this is not to reduce the median [i.e. headline latency figures], but to reduce variability—though it also means that by doing that, you are reducing those underlying [median] figures.”
The exchange is taking the same approach to order entry, where it previously used hundreds of FIX sessions, each with different loads and fill profiles that could result in different levels of latency performance, by optimizing and reducing the number of FIX sessions and supporting microsecond-level latency measurement to give less variance on the input and output of trade data, Studnitzer says. Next year, the exchange will continue to roll out the enhancements to its implied markets—such as crude oil and eurodollar futures—where Studnitzer says CME aims to achieve the same levels of predictability between the median latency and the 99th percentile.
“For non-implied markets, the performance release has addressed both items with order entry and market data disseminated in the same millisecond 99 percent of the time. Implied data has improved and will continue to improve going into 2013, with our goal to ensure 99 percent for implied markets in 2013,” he says. “Our goal was to produce order entry and market data in the same millisecond 99 percent of the time, and reduce the delta between the median and 99 percentile latency to 100 microseconds. As an outcome, the median latency for market data is now 50 microseconds.”"

 

Not sure which part exactly you are referring to but if it's this one:

Then this just means that once you receive your fill you should also see it on the public feed within the same millisecond. Executions and market data are on different links so they're just trying to better sync the two. I dont deem this related to round-trip latency as one's quotes may have been submitted half an hour before they've been hit. I am really just referring to the roundtrip latency where a message to the exchange from your box triggers an immediate acknowledgment or a rejection from the exchange. This should be around 2ms from my experience (this is including internal latency) using a standard commodity technology stack on the CME without being fancy in any way.

I am not particularly interested in this side of things anyway - for me it's just a parameter I need to know. But when I read 120us RTT I think of box-exchange-box trips and that would make a whole lot of a difference to me so I was curious.

 

The Question is how much faster is the direct feed than the public feed? If some ISVs/Market Data Providers have arrangements with the CME on that front, it would still be of assistance.

It looks like the CME really has dated infrastructure compared to something like BATS.

batstrading.com/resources/features/bats_exchange_Latency.pdf

And Currenex can apparently do 850 microseconds:

http://www.statestreetglobalmarkets...506/CS-0002-0152_Currenex_FNL.pdf?MOD=AJPERES

 

I used the two (direct feed/ public feed) interchangeably. Any changes to the orderbook due to places/cancels/trades are disseminated to everyone that are subscribed to the market data feeds and are thus public. The market data feed and executions are on different links and I am referring to the latency of the latter. I haven't measured the latency of the former (not really my department) so can't provide any insights there.

 

When you were measuring execution latency, were you using a direct CME FIX connection, an independent TT-FIX adapter or your FCM's infrastructure to execute, etc.?

Just want to make it clear for future reference.

 

There's a bit more detail to it, but basically through a 3rd party API that sits on top of a direct FIX line.

 

why re-invent the wheel when you dont have to? ther are service providers that focus on that market that have invested into the technology...

you can go with whatever FCM you desire, as long as it is one of the supported feeds.. try embium..

http://embium.com/

I am using their low end product, it can be as simple as you want it or as complex and they are all with execution and feeds at the exchange...

 

Guys, thanks for the contributions. Please don't overfocus on the latency. Perhaps I should've phrased this as a constrained optimization problem: help me think of the set of products that, given the fixed constraint in budget, will allow me to minimize the sum of normalized round trip times. OK?

Thanks for chipping in. I haven't read too deep into the link you've provided but it doesn't seem to be what I'm looking for. We already have a mature test and staging environment and a single point of connectivity for order routing and data delivery. My role with the budget is to reduce counterparty risk, expand and improve on the existing infrastructure - I don't think their product(s) will make any such improvement.

 

interesting that you were able to derive your final decision without evaluating and comparing your requirements to what the product can do or not do....

also, if your role (and what you are getting paid for) is to provide a solution, and you are here looking for answers, then I feel sorry for your group... good luck to you...