I would just add that the whole issue of timing under Windows is
rather a mess. If you want to get resolution higher than the default
you'll have to research a bit to find the implications and gotcha's.
toggle quoted message
Show quoted text
On 7/15/2013 11:07 AM, Richard L King wrote:
rwk, your 'understanding' that Windows cannot accurately measure time
intervals shorter than 65 msec is completely erroneous.
If you're programming directly to the Windows API, you can use
QueryPerformanceCounter and QueryPerformanceFrequency. In .Net, use the
Stopwatch class. With these, you can measure pretty accurately down to the
microsecond level.
These all depend on the presence of a high-resolution timer in your PC's
hardware. This doesn't appear to be much of a limitation - I've never come
across a computer that doesn't have one.
Also if you want to do timer-based actions, you can do these with very
small
intervals by using the timeBeginPeriod to set the minimum timer resolution
(down to 1 millisec). Use createTimerQueue and CreateTimerQueueTimer to
initiate the timers (can't remember offhand what the corresponding .Net
timer facility is, and I don't have time to look it up).
Richard
From: TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>
[mailto:TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>] On
Behalf Of
rwk2095
Sent: 15 July 2013 15:18
To: TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>
Subject: [TWS API] Re: Tick Encoding/Decoding
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.
|
