Realtime data returned by TWS from reqMktData() does not contain a timestamp. ib_insync itself adds the timestamp using your computer clock. So indeed there is no way at all to know when the tick was 'really' produced.

?

Data returned from reqTickByTick() DOES include a timestamp, but it's limited to a resolution of 1 second. I don't know offhand if it's added by the IB servers or by TWS, but I think this has been discussed before so try searching.

?

IBKR does not aggregate data returned from reqMktData: it samples it. If you compare the data returned from reqMktData with a source that definitely includes every tick, you find that every tick from reqMktData is in the full data, but not vice versa.

?

The sampling mechanism is very simple. Time is divided into fixed length intervals of around 300 millisecs for stocks and futures and 100 millisecs for forex. For any given instrument, the IBKR market data server records each tick as it arrives. At the end of each period it sends the current value for each tick type to TWS, but only if it is different from the value set to the user at the end of the previous period. To enable this to happen, it must also keep a record of what it sent last time.

?

This has implications: in particular, if the previous value for 'last price' was, say, 1500, and during the next period the exchange sends one or more trade reports with different values, then at the end of the period only the latest 'last price' is sent to the API, and if that happens to be the same as at the start of the period then no 'last price' is sent at all (but a 'last size' might be sent if that is different, and a 'volume' will be sent because that has increased). This mechanism explains how the reqMktData stream sometimes results in highs and lows of bars being incorrect by a tick or two: they just weren't sent because no change from the start of the 300ms period had been detexcted.

?

Given that there are many tens of thousands of TWS users at any one time, many of whom will have large numbers of tickers running, this might sound like a massive amount to keep track of, but it's actually quite simple (though this is speculation – I don't know for certain exactly how IBKR manage this). If the time period length is 300 millseconds, you could imagine that the IBKR data farm has 3 servers for a particular stock or future. When a user requests data for that instrument, he is allocated to one of these 3 servers, and all his subsequent data (for that instrument) come from that server. Thus that server only needs to record one set of previously sent ticks, not one for each user. And that server now has 300 milliseconds ?to send out each tick to all the users it services, so the load is fairly constant and predictable. Obviously one server would serve data from many different instruments, and conversely each instrument's data would be disseminated to by multiple servers, but the whole thing can be sliced and diced and load-balanced in such a way that the tick data stream is never more than 300 ms behind the market.

?

When I first starting investigating this mechanism back in 2003, every market data line in TWS and every market data request via the API counted against your allocation of 100 tickers, even if you requested the same ticker more than once. This was presumably because the request was allocated to a different server, and in fact the data streams received were different.. But at some stage in the late noughties (I think) this was refined so that the same request from the same user was only counted once: so now, if I request data for a given instrument from several different API client programs, that is only counted as one market data line, and they all receive exactly the same data (and that even applies whether the data is requested via the live or the paper-trading account).

?

Sorry for the lengthy reply, but I think it helps to have a clear picture of what is going on here.

?

?

?