开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育

Re: Timestamp for streaming market data and tick by tick?


 

The concept of "market lines" is explained at and cost details for quote boosters at
Without boosters, you have 100 market lines and, consequently, Level 2 data for up to three instruments per the table.It never came up for us but the way I read the table is that you'd have to

  • purchase four boosters to get Level 2 data for a total of four instruments
  • purchase five boosters for five Level 2 data streams total
  • ?...

You can purchase a maximum of 10 boosters so I guess the absolute maximum is 1100 market lines and Level 2 data for eleven instruments. At that point it may make sense to look at a real-time market feed provider. Keep in mind that data services and other API functions at IB have been designed for the support of a human sitting in front of the Trader Workstation. So there are lots of limitations.

The 3.5ms I mentioned is the "one way packet flight time" I have measured between my cloud instance and ndc1.ibllc.com and is calculated as one half of the round-trip ping time (which is just over 7ms). This was more of an "order of magnitude" example.

I don't think that there is a lot of time wasted. Keep in mind the API you are using is only for the connection between your client and TWS/Gateway and the message format are quite efficient. You do not communicate with IBKR servers directly and the connection between TWS/Gateway and IBKR servers is already FIX or similar. I can't see a reason to think about FIX unless you'd also colocate your server with IBKR to get the packet flight time down into the low microseconds or even nanoseconds. It is a completely different game at that point. But the FIX capabilities are documented at if you want to take a look.

Your question yesterday made me curious so I ran some stats on the 10 Million or so TickByTickTradeAll data objects and 50 Million TickByTickBidAsk objects we processed in January 2021 for ESH1:

Our system records an arrival time stamp (currently in ms) and each arriving object gets a unique serial number so that the arrival order can be maintained (despite the 1 second trade time resolution). The system clock is pretty stable with a long term average offset of only 1 micro second.

So I calculated arrivalTimeInMS minus (TickByTickTimeStampInSeconds * 1000) and plotted the result (see below and attached PDF):

  • The fastest reports arrivals with a lag of 3ms, but only very few arrive this quickly
  • The most frequent arrival delay is 770ms with another peak at around 1,030ms
  • Average and median arrival delay is around 870ms with a standard deviation of 385
Hope this helps/

Join [email protected] to automatically receive all group messages.