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.
toggle quoted message
Show quoted text
--- In TWSAPI@..., "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.
|
