Due to recent additions to the api it is important to distinguish
between all the different data streams that are available.
In the old days 'tick data' referred to the live data in reqMktData,
which is sampled and not individual ticks.
Then realtime volume came along which was still sampled (but in a
different way) and included millisecond timestamps which were, as
Kurt said, bogus and derived from the local clock.
Now there is reqTickByTick data which is close to actual non-sampled
tick data (no one with access to a high quality data feed has posted
here as to how 'un-sampled' IB's data is).
Obviously trades-at-bid and trades-at-ask can't be done on a sampled
feed. IB's historical TickByTick data is also not useful since there
is no way to reliably combine the separate Last and BidAsk streams.
From what I have seen so far the live TickByTick data updates such
that trades-at-bid and trades-at-ask can be determined since the
events arrive in a coherent order. I do not have access to a high
quality data feed so I can't make any definitive statements about
IB's TickByTick data other than it might be good enough. Each person
has to research it and see if it meets their needs.
On 9/3/2018 12:47 PM, Kurt Bigler
wrote:
toggle quoted message
Show quoted text
I'm pretty sure when this question came up years ago it was
concluded that the timestamps on tick data are put there by
TWS/Gateway, based on time of arrival. ?They are not real
timestamps based on market events. ?They are a "convenience" for
API programming.
Therefore you are just as good generating your own timestamps
based on when you receive the ticks, or if order is all that
matters, to simply make use of order of arrival. ?You can
therefore use any time resolution you want. ?However
simultaneity will always be a little ambiguous. ?For sure you
will need to make sure your reading of the stream is not blocked
significantly waiting for a timer, etc., and you will want to
discern the degree of delay between ticks to determine whether
you treat two events as being "at the same time".
-Kurt
The timestamp is only in seconds so when there are
multiple ticks per second you have no way to determine
the order of events.
For active instruments there will be multiple ticks per
second so your approach will not work.
On 9/3/2018 6:37 AM, hannnnny
via Groups.Io wrote:
I'm
thinking of a kind of lookup algorithm based on
timestamp to slot the trade ticks into the bid/offer
ticks, I was just hoping someone has done this already
but do you know some reason why this can't be done??
