I am trying to request real-time tick by tick data, but data arrives with timestamp missing milliseconds. Here is my code:

Timestamps within the IBKR API are generally "Epoch Seconds" and there is nothing you can do to get actual? higher resolution time stamps.

We work around that by recording high-resolution arrival time stamps (Java Instant, nanosecond resolution) in addition to the "Epoch Second" plus an index that maintains temporal order of all arriving data times.

闯ü谤驳别苍

Thank you so much!?
Just out of curiosity, how do you estimate delay time? (difference between trade timestamp and arrival stamp). Do you buy data feed with more granular timestamp?

That's a good question. Let me share what this looks like for our specific setup, but there are so many variables that your results (and those for everyone else) will vary greatly.? But maybe our approach helps you make your own measurements.

So we are looking for the order of magnitude of the time it takes for the information about a trade or order book update to travel from the exchange to our application when using IBKR TickByTick data feeds. Here is our setup:

• We are mostly interested in VIX and ES futures that are both traded in Chicago. We analyze IBKR data feeds for TickByTickLast, TickByTickBidAsk, TickByTickMidPoint, and Level II order book updates.
• We have a virtual server in the east of the US with a very fast (as in latency) internet connection and we connect to the ndc1.ibllc.com IBKR east coast entry point.
• Our average round-trip latency to IBKR is around 7.75ms, so that the "flight time" for data feed packets from IBKR to us is around 4ms
• Add to that the flight time for packets from Chicago to the east of about 10.50ms (more about that later) and you will land up with approximately 15ms for just the "flight time" from the exchange to our server's door step

I mentioned before that we tag incoming data with a high-resolution arrival timestamp and an index that maintains temporal order for data from the various IBKR data feeds we subscribe to. Our applications are multi-threaded, implemented in Java and we use (a pimped version) of the TWS API Java ApiController class:

• To estimate the delay, we look at the first trade (TickByTickLast) that IBKR tags with a time stamp of 08:30 Central Time
• We use this approach since it is very likely that trades take place early in the first second after 08:30 Central Time.
• The metric is the difference between the IBKR provided trade time (in seconds) and our high-resolution arrival time stamp in nano seconds (but with an effective resolution of one micro second) averaged over several years worth of data

With that long disclaimer, we get for IBKR TickByTick data feeds for CBOE/CME futures:

• An average delay of 36ms at a standard deviation of 30ms and a median delay of 27ms
• In the first second after 08:30 we see an average of 1,928 data events with a standard deviation of 1,224 for the instruments we subscribe to. Median is 1,368 events and the busiest we have ever seen was 7,005 events in that second.

By coincidence we have a (real) server in a tier 1 data center just north of the CBOE/CME Aurora/IL data center (as in hiking distance). The server is not trading related, but we use is for latency monitoring of IBKR and our own applications. That server has an average round-trip latency to IBKR's cdc1.ibllc.com of only 3.0ms (one way flight time of 1.5ms) and the delay between IBKR and CBOE/CME will probably be in the same order of magnitude or slightly less. We could probably shave about 12ms off the delay numbers mentioned above if we were to move TWS and our client applications to the Chicago server.

Similar measurements for other "busy seconds" through the day confirm delay figures for CBOE/CME futures related TickByTick feeds in the same order of magnitude.

Hope this helps.

闯ü谤驳别苍

Thank you for such a comprehensive reply. I like your estimate around 8:30 very much. I think everyone can do something similar.?

开云体育

We are not correcting tick timestamps, Richard. We simply have exact arrival timestamps (Java class Instant) for all kinds of events, including for when TWS API callbacks take place. More background on that below. These high-resolution time stamps are not used for any trade decision making.

But we do occasionally use them for response time and latency monitoring such as estimating Tick-by-Tick data streams event delays. In other words, how much times does it take for the information about a trade or order book update at the exchange to arrive in our client in the form of Tick-By-Tick callbacks?

When you look at the IBKR one-second resolution time stamp of a Tick-by-Tick object you generally don’t know whether that event took place towards the start of that second (say a few micro seconds into the second) or towards the end (nearly 1,000ms later). But for VIX and ES futures, for example, the first data we receive after market open at 17:00 Central and the start of the liquid trading hours at 08:30 Central almost certainly took place at the exchange very close to 17:00:00.00000000 and 08:30:00.00000000. Therefore, the difference between that timestamp and our high resolution Tick-by-Tick callback arrival timestamp gives us a good feel for the order of magnitude for that delay. For our setup the median delay (over a a few years) is 27ms. And while that is an eternity for a HFT system, for what we are doing it means that we have a very timely real-time view of what is happening at the exchange when we monitor Tick-By-Tick data streams.

So, why do we even have these high resolution timestamps.

The fancy term would probably be “orthodoxies”, or in plain words “old dogs, their habits, and their tricks”. You may recall that my background is not in finance or trading but rather in computer systems architecture (general purpose, fault tolerant, embedded, distributed), operating kernel internals (Unix, Linux, WindowsNT), and large scale real-time and signal processing systems. So when I stumbled over the TWS API and started exploring what I could use that for, I had a rich set of tools, libraries, and frameworks at my disposal to base our framework on. And these were all oriented around streams, events, messages, reactive systems, and asynchronous processing. The TWS API has shortcomings, but the asynchronous and non-blocking nature fits right into what I had.

And then there was this other blast from the past, called Six Sigma, that encourages you to measure and record everything you can afford to. You may not know exactly what to do with the data right away, but there will be questions in the future where that extra data and context suddenly becomes crucial.

So for us, everything is an event, events lead to streams (or flows) and streams can be distributed, shared, persisted, split, combined, filtered, aggregated, processed sequentially or in parallel, and manipulated in all kinds of creative ways. Whether that is a Tick-by-Tick data object or an execution report we receive from IBKR or a trading decision, an order placement or anything else.

That view of the world is greatly supported by a development practice we had acquired over the years that favors smaller classes where virtually all instantiated objects are immutable (e.g. all fields are “final” and no object state changes after construction). These immutable objects can now freely enter into parallel streams and can be processed without any risk of undesirable side effects. For the most part, making an application consists of orchestrating the kinds of event input streams the application needs, the ones it generates, and the various required processing steps.

When an object turns into an event it gets a high-resolution timestamp (the Java Instant) as well as a unique identifier that allows us to remember the temporal order of these events even if they take different paths through the streams, are aggregated, or come back together later.

And the best part of this system is an EventLogger that can consume any and all of these streams, serialize events and related objects into Json streams (even if it has no idea what these objects are) and persist them to files. The logger rolls and compresses these files every 15 minutes (configurable) so that we have compact records of everything that took place during those times. We can go back to these records later for analysis or, due to the high resolution time stamps, combine them with other data or events.

We can also replay these logs with extreme fidelity in case we make changes or want to try different configurations. For example, our trading strategies are not aware of whether they actually communicate over the TWS API or whether they operate on stream replays. or in simulations.

And finally, the EventLogger has eliminated most of the traditional application logging. Application code (or stream processing modules) generate events that are logged along with all other events and objects and, in case of the need for debugging, a rich set of hints and real objects exist to go back to.

So when the Tick-by-Tick data delay question came up, we had enough “context” recorded over long periods of times to quickly come up with a good estimate.

Hope that helps and makes sense,

闯ü谤驳别苍

On Thu, Aug 4, 2022 at 04:13 PM, Richard L King wrote:

开云体育

This post gave me more just simple answer. I still curious. Why would not IBKR add milliseconds to their timestamp? It does not look like too much work for them. Have anybody tried asking them? Is it worth trying?

IB's timestamps are likely generated from IB's server and not the exchange's timestamp.? I've watched IB server time via reqCurrentTime() and usually observe the server time drifting slower over the course of 4-5 minutes until its about 1 sec behind.? Then it resets back to the correct time and the process repeats.?

While not tick-by-tick, reqMktData will return a timestamp with milliseconds but it has the same time drift problem.? Millisecond precision isn't very useful if the accuracy is only 1000 ms.

Thank you, Millie!

Time drift is something interesting. Just to make sure that I understand, when you said "1 second behind", do you mean behind exchange time?

I'm comparing the ms timestamp that IB sends in RT_TRD_VOLUME (presumably exchange time) to the time my computer receives that message from the API.? IB's timestamp is always earlier than my computer's time but the difference varies systematically from approx 50ms to 1000ms, which makes me very suspicious of the accuracy of that timestamp.

Here's an example of some typical timing observations from this evening