The only legitimate complaint you could have is if IB's servers were not properly synchronized with one of the official time clocks. As far as I can tell you have not made that claim. Anything else is pointless. IB sync's with the public NTP servers and you sync with the same public servers. You don't need to sync with IB's clock as long as you as everyone is sync'ing using a common reference. Now let's talk about why ET's servers are consistently out of time sync.... how hard is it for them to run an job once a day to keep them synchronized?
What he is saying is that automated system is based on closing price. Software will close bar (candle) on computer internal time. So system might generate a signal which might not be a signal should the clock be synchronized with TWS. Now think hard. If your system gives an early signal based on computer clock, that could be favorable and unfavorable. (IB has no idea when your system will generate a signal).
If you were talking about a forex broker with a dealing desk, I'd be very concerned. But IB is a public company. I don't think it's a deliberate attempt to slip a few ticks out of you. ~Mike
If that is the case and IB's API does not timestamp data then *that* should be the complaint. The end-user should not be assuming the timestamp of incoming data based on their local clock - the timestamp should be included in the data format. If IB doesn't timestamp their data then that just reflects badly on their API.
The issue is so simple. IB DOES have an internal timestamp that they use to turn over THEIR charts every event period. So why dont they allow THEIR customers to access it. Given how crucial time stamping is why I am I left guessing what time standard THEIR adhering to. Wouldnt it be much easier to allow all of the many applications that feed off of their system to synchronise exactly with their internal time stamp that does exise instead of basicaly not allowing customers applications to create Cling film strict adherence to their internal charting apparatus. In my opinion they wont allow their clients to build the necessary level of adhesivenes into their applications because they dont share their internal server time clock. It also makes me wonder why someone so concerned with my spelling of the word their cant see the essential point that Im driving at or doesnt feel it amkes any difference. Because in a world that is time driven knowing what your feeders time clock says is absolutely 100% essential to feeding off of it.
For streaming live data, no time stamp is needed. The differential is in milliseconds. If anyone insist on time stamped streaming live data, there is always eSignal, etc.
I disagree. MBT includes timestamps in their streaming real-time tick data and during certain heavy trading periods you can see the data is lagging by seconds, not milliseconds. Being able to detect and understand that the data you are seeing (or processing in the case of an ATS) is lagging is critical. Simply assuming that the data is always real-time (not lagged) is a flawed design IMO, even given IB's aggregated method of data delivery which does not tend to lag data like MBT's full tick data stream does. IB doesn't control the packets once they leave its network. The lagging could be happening enroute.
IB aggregates its quotes, that's why you do not see delay even during high market volatility. Because the data is aggregated, time stamp cannot be applied. I doubt IB would/could ever offer a time stamped live data. For data purists, IB is not the solution.
I do not believe that IB-caused delay is impossible, even with their aggregated quotes. Server-side issues can always occur during unusual periods. Further as I previously mentioned network delay is still a possibility that needs to be accounted for. I don't follow - why couldn't IB include a timestamp that indicates the start or end of the aggregation period? No argument from me there.