开云体育

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

Re: Tick Encoding/Decoding


Ed
 

I don't think there is a strict correlation between tick price/size
and RTV. They seem to be completely different streams to me, with
different sampling/aggregation.

Remember that IB does not send each tick and you get about 3 updates per
second.

On 7/16/2013 4:15 AM, unatnahs57 wrote:


Yes its java, your tools sound quite interesting..

The time lag was simply the local time when I get a IB response, in
milliseconds. The lag I meant was the time lag between when i get
tickPrice and RTVolume. Seems first I get "id=0
lastTimestamp=1373851042" response, then tickPrice/tickSize response
and then I get RTVolume. Also, appears that tickSize response can come
even after RTVolume, as if two threads are writing the callback response.

--- In TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>,
"rwk2095" <r@...> wrote:



Your original post (OP) makes more sense now. I was unfamiliar with
TickUtils.jar because it appears to be Java, and I don't speak Java.

It sounds like I am doing something similar to TickUtils.jar. I
write quotes and trades into a file of fixed-length records, 20 bytes
each, which I refer to as a blob (binary large object). I then load
the blob into memory for detailed analysis at my leisure using a
single read command.

As Richard mentioned, a blob is not directly readable, but I have
tools that extract pieces and put them out in .csv format for analysis
in Excel. I also have a playback tool that can replay a segment of the
day at whatever speed I select.

If you're using the RTVolume generic, you might also specify the
"mdoff" flag to suppress quotes in the regular quote stream so that
you're seeing only trades. This saves bandwidth. If you need quotes
too, you can get them from reqMktDepthEx().

I don't understand the time lag you mentioned. How are you measuring
the lag? It's my understanding that Windows cannot accurately measure
time intervals shorter than about 65 msec. I believe the regular data
stream from reqMktDataEx() is unsuitable for understanding market
microstructure.

[rwk]



--- unatnahs57 <no_reply@> wrote:
1. I am making data request as: mClientSocket.reqMktData(id,
contract, "", false);
which returns the "last price and quantity in separate callbacks".

So, using the post #24461 that you suggested I made the request
as: mClientSocket.reqMktData(id, contract, "233", false);

which returns Last Trade tick as:
id=0 RTVolume=3066.00;4;1373851042866;1108;3065.15771661;false

I can now construct the LastTick object instance used in
TickUtils.jar.

(Not yet sure if BidTick, AskTick can be done this way, but I'll
investigate further, I wanted to reply at the earliest).

++++++
2a. I also noticed an interesting thing. Request made with only
"233" still gives me IB response for tickPrice, tickSize methods, so
I'm actually using more bandwidth.

2b. Also, please take a look at the data below (I tested $NQ_F)

2013.07.14 20:17:14:836,0,6.0
2013.07.14 20:17:15:759,0,7.0
2013.07.14 20:17:20:208,0,6.0
id=0 lastTimestamp=1373851042 <-tickString() response
2013.07.14 20:17:21:989,4,3066.0 <-TRADE_PRICE
2013.07.14 20:17:21:993,5,1.0 <-TRADE_SIZE
2013.07.14 20:17:21:999,8,1105.0 <-VOLUME
2013.07.14 20:17:22:004,1,3065.75
2013.07.14 20:17:22:014,0,4.0
2013.07.14 20:17:22:021,0,4.0
2013.07.14 20:17:22:025,3,6.0
id=0 RTVolume=3066.00;4;1373851042866;1108;3065.15771661;false
2013.07.14 20:17:23:132,5,3.0 <-TRADE_SIZE
2013.07.14 20:17:23:233,8,1108.0 <-VOLUME
2013.07.14 20:17:23:324,0,5.0
2013.07.14 20:17:23:328,3,7.0
2013.07.14 20:17:24:052,0,6.0

i) There is almost a 030ms (average seems to be like 040ms) lag
between when trade is executed and when we get RTVolume response.

ii) I get a tickString response timestamp, then I get a trade,
trade size, tickString Tick data, then trade size and then volume upto
that point. Seems 2nd trade_size is not preceded with TRADE_PRICE if
the price is same as last traded price.

iii) Seems we can construct TRADE ticks using tickPrice stream
ourselves, although VWAP might get messed up if data breaks in between.

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