I had a conversation with a HFT practitioner this afternoon, and he (as well as @garachen) touched on my inability to know CME's internal latency being a major oversight in my backtesting. Can anyone give me any information on the distribution of internal latency observations you experience with CME? To be clear, I'm not talking about MyServer -> CME or CME -> MyServer, that I can take a fairly good guess at. I'm talking about the internal CME step, namely ReceivedByCME -> BroadcastedInFeed. I've had a pretty good look at CME's documentation and nothing has come up. Thanks.
Found this. Doesn't offer much info, but definitely implies a downward trend year over year and a positively skewed distribution. Numbers are also just high, so much so that it probably significantly impacts how deterministic of a backtest you can get. Would still appreciate some further thoughts from folks here.
This should be part of regulations regarding dissemination of market information by the exchange and it can vary depending on market conditions. Is this correct for CME? I am not sure myself but if I find something I will certainly post.
The document you cite does not list G-Link, which is their 10Gb connection at Aurora, but it does discuss collocation. I thought that collocation in the same location as their matching engine was not available until after they moved the matching engine to Aurora, so it is strange to me that G-Link is not listed. The document also does not define the end points of the rtt calculation so it is difficult to know how to use that info. They provide 2 time stamps on their messages. One which can be used to indicate the time at which the an action was taken which caused the message to be generated, and the other which is the time just before they send it out. We call the first time stamp the host or source time stamp (sts) and the second, the jumping off point (jop). We have noticed during some news events, that jop - sts can be as high as 18 milliseconds. I do not have much experience analyzing strategies with historical market data but I would think that given the relatively long time a report about an order can remain at the exchange, without sts and jop info most such analysis would not be accurately predictive. In addition to the time at which our system has received a message, we are beginning to make available to our users the sts and jop info. Perhaps someone will use such info and post an analysis on it.
Well the 18 milliseconds stat certainly explains the positive skew. I looked around quite a bit trying to see how CME defines a round trip and didn't find anything, unfortunately. You now offering the "sts" and "ptp" timestamps is awesome. That's something I'd be really interested in. Is this going to be for all market data updates, or just actions/trades which the user is a part of? This could ameliorate a pretty major cause of uncertainty w/r/t my backtesting if that's the case. Thank you as always.
If it is available from the exchange we will offer it. No other exchanges offer the jop as part of the data in the message. The CME provides this info for execution reports and I believe for market data as well. If so, then both will be provided. Another feature that may be handy is that the CME is providing traders with the ability to remove some anonymity on an order by order basis. This means that a trader can mark some orders as non-anonymous and mark other orders to remain anonymous. In this context non-anonymous means that the market data that is published in response to certain events will contain data that identifies the event to the event creator. The simple case is that a market data trade message may now have associated with it an id (order id, fill id, ..., ?) that only the sender of the order will know. So a trader can see where his order is in the stream of market data messages. As of this writing I am not sure which id will be present and which events (new order, modify, trade, ...) will cause this to happen but we will be making this feature available to our users shortly.
Thanks for the info here, apologies for mixing up jop and PTP for some reason above. These are both great features and I appreciate that rithmic is interested in allowing customers to look at and utilize the full breadth of information and functionality of the CME direct feed. You've really piqued my interest with the possibility of getting jop - sts for market data updates as that would be really helpful for backtesting. Could you possibly confirm whether it is indeed the case that it is available for market data updates? Thank you.
Very interesting thread. Thanks to all participants. I am currently writing the matching engine layer of a new backtesting application and am looking to model latencies that do not relate to transport. Does anyone have an up to date average figure for non-exceptional market conditions? Any other hints or tips also much appreciate.
Having played with this a bit, I'll give you my personal opinion. If you're backtesting on that low of a level, just having a "figure" isn't gonna be meaningful. When the matching engine gets busy, the median latency is just blown out of the water because the distribution has a very heavy right tail. Even knowing something about the distribution isn't really worth too much in my opinion, but it's a lot better. If you just blindly assume say 50 microsecond latency to CME, you'll probably find you've solved the market making problem within the first two or three days. It's unrealistic. Like I said, even if you know the distribution, it's just not the full picture, because the other 2000-something active market makers in the U.S. all shelled out to record the CME feed and their TCP sessions. Rithmic is moving towards a good solution here. I recommend you take advantage of what they're working on above if you're shooting for a GarageBand prop trading company type of backtesting software as I am.
Thanks for your thoughts. I should clarify, I'm not looking to make markets. To be honest, I'm currently rolling a new completely backtesting suite and simply thought I may as well make the effort now to futureproof it and model down to this low level. However, since finding this thread I've been thinking further, and it occurs to me that such a huge negative skew might present tradable opportunities (I am still amazed sts-jop can shoot out to ~18ms). I'm wondering if, using some well timed anticipatory orders, during news events I might be able to pick off those who haven't factored in that massively increased internal latency. Hmmmmmmm....