I have a question for those people that understand the nuts and bolts of market data streams. For reference, I'm using a Zen Fire feed and the main instruments I trade are the CME FX futures. When the price or volume at the top of the book changes then this is obviously reflected in both the L1 and L2 data streams. However, I am sometimes seeing situations where these get wildly out of synch. For instance, a data message indicating a change of volume on the ask might sometimes arrive more than a second later on the L2 data stream than the L1 data stream. Now, I would expect that in fast markets if there's any lag then it should occur equally on both data streams but apparently not. There's only one event occurring at the exchange to generate both these messages (the act of the posted volume being changed), so you'd assume the exchange's data feed technology would generate both the L1 and L2 messages at exactly the same time. Has anyone else noticed this, and if so, do you have any ideas as to why it might be occurring? I'm sure it's something obvious that I've missed. Many thanks in advance for your thoughts... P.S. I've posted this in the 'automated trading' forum as I'm assuming that it's only going to be algo traders such as ourselves who are going to be concerned by such things.
This is a frequent occurrence. The Level II data projects depth of market for 10 levels = 10 quotes, Level I broadcasts bid/ask/last. CME updates the feed every 14ms but many data providers filter and throttle the data you receive. Keep in mind in fast moving markets the data is already history by the time you receive and process the updates. Our solution was to build an "executable" price feed based off of the Level II data. We calculate the averaged bid/ask price to fill 54 contracts (Our max order size) from the level II data. This filters out much of the noise. Especially when Level 1 price reflects 1 - 5 available contracts. Less surprises and our fills 99% of the time are what we expected or better.
Well, given that the Zen Fire/Rithmic platform sells itself on providing unfiltered and unthrottled data I should be receiving everything that the exchange pumps out. Even though there's more data messages being generated on the L2 data stream due to the additional depth of market, I still don't understand why messages relating to the top of the book should be out of synch. Both the L1 and L2 data messages should be generated synchronously by the exchange because they both relate to a single event within the exchange's matching engine. The only way L2 could lag so badly is if there was a cached backlog of L2 messages on the exchange waiting to be sent...and I just can't believe that the CME is using a platform that allows a backlog to build up that's big enough to take a full second to clear. I mean, 1 second is an eternity in the HFT arena.
Unless you are receiving 70 updates per second per quote you are receiving partial data. As far as i know CME only time stamps last trade. For 6E you would be receiving 770 updates per second. if you are HFT in milliseconds you should colocate at equinix and get a fiber connection to the exchange. What CME processes on their computers and make available to their licensed data providers is different then what you ultimately receive depending on the transport mechanism. ie. RTD/DDE/COM.. The most efficient feed I've tested for Level II was actually Bloomberg DDE because they transmitted the data feed in an array. Try monitoring the ES feed and calculate how many updates you receive in a one minute period. Record starting volume and ending volume and last trade size. Add it up and the difference will give you an idea of how many updates your missing.
This is where I would point. Using NInja as I still do on some stufff. I have chart windows out of sync with each other sometimes by some seconds. What front end do you use? Is it possible... that this simply is not doing a decent job?
Yes, I'm using the Ninja API. I know that Ninja has serious UI performance issues due to their threading architecture...perhaps they also have performance issues with the threading for the L1 and L2 data streams. JJW's hypothesis definitely sounds reasonable. I think what I'll do is this: 1. Subscribe to both the L1 and L2 data streams for a single instrument (let's go for the ES to get max data volume) using both the Ninja and R APIs. 2. Dump all the L1 and L2 events as they are raised into separate log files (one file for each API). 3. Run a file comparison utility over both the log files to pick up on any discrepancies. 4. Examine whether these discrepancies point to Ninja suffering lag on the thread dealing with raising the L2 events. P.S. My machine isn't struggling with the load. With Ninja the CPU never usually gets above 40% and with R-Trader it hardly registers anything. I suspect, as you say, the issue is probably due to Ninja's multithreaded handling of the 2 datastreams.
Sounds more than reasonable. Whever Ninja is involved, I am reluctant to point fingers to anyone else in the first place They are FAR too likely to have some brain dead design decisions or simply programming errors somewhere along the path to start with With your approach you can acutally compare the data. I would not wonder if anything gets lost in the Ninja internal processing.