开云体育

That is my understanding, Neal. I work under the assumption that fields such as "time" returned by all TickByTick data feeds as well as? "Last Timestamp" tick #45 represent the epoch time with 1 second resolution for those events at the exchange.

The RtVolume ticks #48 and #77 provide time with 1 milli-second resolution, but it has been suggested that those time stamps are actually generated by TWS and do not represent the time at the exchanges. I have not done that much work with them but that feels correct.

My server is NTP synchronized against a high-quality time source in the data center and nudges time by a few micro-seconds (usually less than 5us) every 16 seconds.

We cannot guarantee that the order of event arrivals at your client is the exact order of the events at the exchanges. Especially if you look at data/events from several exchanges, IBKR market data farms, and IBKR order processing. But the arrival of data for any given stream (say TickByTick Last and TickByTick BidAsk for the same instrument) looks to me as if they are "in order". Even streams for multiple instruments from the same exchange feel like they are substantially in order.

The order will likely not be exact if you compare data from sources with very different latencies (say Europe, Asia, US East, US Central).

It was always good enough for what I am doing (even at the sub-second level. If you need more you'd have to co-locate with IBKR or the exchanges, switch to FIX without TWS/IBGW, and have dedicated hardware time synchronization.

闯ü谤驳别苍