IB's Data feed

Fully concur with your points re ib server time.

This is complete bullshit. Sorry.

Run Sierra Charts. When you load, the log gives you the difference between server time and your computer time.

Do a time sync with time.nist.gov or time.windows.com and the difference disappears.

If you don't know what the fuck you are talking about, don't say anything.
 
True (unless you connect via Fix directly to IBs server) but ib server returns the server time which has nothing to do with your local time. It's perfectly apparent to me because I connect from a different time zone and get EST back from ib.

When I have time I will check this again. From the programming point of view the connection is between TWS instance running on local machine and client application. TWS itself is a client application of remote IB server. IB documentation always refers to TWS as server. IB server is not directly accessible.
 
Last edited:
Could you try to be more precise in your English? It's very hard to understand what your problem is and what you try to accomplish.

Hold your horses guy, Sierra Charts it is as Visual Studio for big money!

Do you understand that delay may be very big sort of some power off or an connection lost ...

As the results we can use it as tikePrice + localtime is it over? And reqHistoricalData can we used only once? I got error: Duplicate ticker ID for API historical data query when try got HistoricalData again.
 
Could you try to be more precise in your English? It's very hard to understand what your problem is and what you try to accomplish.

I want to get the tick price with date and time, for correct charting!
IB ignores the fact that between client and IB's server may be some delays and provides tick prices without date and time or provides data via RealTimeRars having a delay of 5 second (Why more 5 seconds, but not less than a second?).

Because of this, I can't build correct price chart!

Have you checked what do PriceTick if turn off wifi on 5 minuts? Yes PriceTick returns all data for 5 minutes at one moment. And what to do with it?

IB need to change PriceTick and add date and time! It will be right!
 
Last edited:
Sure it would make the api more complete yet I still don't see what your problem is. Just time stamp the incoming locally as long as you make sure your time stamps are all converted to match the same time zone. It's not like this is hft data, those are snapshots with 200-300 ms update frequency and hence it is not relevant whether the time stamp occurs on their server side vs your local machine. It's api has much bigger issues than this so I do not see a big deal with time stamping your near real time snapshots.

I would never subscribe to live updating bars.subscribe to real time data and build the bars yourself. Very simple.



I want to get the tick price with date and time, for correct charting!
IB ignores the fact that between client and IB's server may be some delays and provides tick prices without date and time or provides data via RealTimeRars having a delay of 5 second (Why more 5 seconds, but not less than a second?).

Because of this, I can't build correct price chart!

Have you checked what do PriceTick if turn off wifi on 5 minuts? Yes PriceTick returns all data for 5 minutes at one moment. And what to do with it?

IB need to change PriceTick and add date and time! It will be right!
 
Sure it would make the api more complete yet I still don't see what your problem is. Just time stamp the incoming locally as long as you make sure your time stamps are all converted to match the same time zone. It's not like this is hft data, those are snapshots with 200-300 ms update frequency and hence it is not relevant whether the time stamp occurs on their server side vs your local machine. It's api has much bigger issues than this so I do not see a big deal with time stamping your near real time snapshots.

I would never subscribe to live updating bars.subscribe to real time data and build the bars yourself. Very simple.

Thank conduit, but 5 seconds of delay for the open session it's a big problem! Me need not more than 1 sec, it's my limit!

So wiil be change me approach!
 
Then don't subscribe to those damn realtime updating bars. Either pull historical data or subscribe to real time data. Simple as that. The devil lies in the detail later when you really understand all the pitfalls of blending.

Why you keep on talking about those 5seconds?if you build your own bars off realtime data and blend them with your historical data you request and receive then you have a perfectly fine continuous data stream. Updates of current bars come in every 200-300ms.

Thank conduit, but 5 seconds of delay for the open session it's a big problem! Me need not more than 1 sec, it's my limit!

So wiil be change me approach!
 
We have alredy talked about this above, this's IB's a bad. If IB add date-time stamp in the PriceTick (or last price) we don't have this a problem!

Then don't subscribe to those damn realtime updating bars. Either pull historical data or subscribe to real time data. Simple as that. The devil lies in the detail later when you really understand all the pitfalls of blending.

Why you keep on talking about those 5seconds?if you build your own bars off realtime data and blend them with your historical data you request and receive then you have a perfectly fine continuous data stream. Updates of current bars come in every 200-300ms.
 
Last edited:
Real-time-data can got via PriceTick or RealTimeBar. 5sec - this is about RealTimeBar.

Else we can use RTvalue as an alternative, but this's an absolute chimera of programing!
 
I want to get the tick price with date and time, for correct charting!
IB ignores the fact that between client and IB's server may be some delays and provides tick prices without date and time or provides data via RealTimeRars having a delay of 5 second (Why more 5 seconds, but not less than a second?).

This is from the doc of API 9.72:
"void reqRealTimeBars(...)
Requests real time bars. Currently, only 5 seconds bars are provided. This request is subject to the same pacing as any historical data request: no more than 60 API queries in more than 600 seconds. Real time bars subscriptions are also included in the calculation of the number of Level 1 market data subscriptions allowed in an account. "

Do you need sub-5s-bars? Really? :)
As others already have suggested: build your own bars, only then can you understand the technicalities behind it...
 
Last edited:
Back
Top