|
|
Home
Search
Register
Login
Recent Posts
| Viewing User Profile for: brgv | |||||||||||||||||||||||
| About | Contact | ||||||||||||||||||||||
|
|
||||||||||||||||||||||
| Post Statistics | |||||||||||||||||||||||
|
brgv has contributed to 7 posts out of 21191 total posts
(0.03%) in 5,063 days (0.00 posts per day).
20 Most recent posts:
Data and Content Support »
Tick data discrepancies between Streaming Level-I quotes and Historical tick data Jan 3, 2011 11:17 PM
(Total replies: 7)
Thanks Steve The first bulleted point on 4.7.2.0 release notice explained the same problem in detail. Damn, I knew there was something obvious that I was missing :)
Data and Content Support »
Tick data discrepancies between Streaming Level-I quotes and Historical tick data Dec 28, 2010 12:31 PM
(Total replies: 7)
Quote: Thanks for highlighting that 'anchor', brgy. I think the tick that came in streaming level-I was legit, I was wondering how others handle such busted trades.--- Original message by Johnny Abodhi on Dec 28, 2010 09:09 AM Am I supposed to look at other fields that exclude such ticks as legit trades? Forum, Please help! I am trying to find out if am missing something obvious in dealing with such ticks
Data and Content Support »
Official US time Dec 28, 2010 12:15 PM
(Total replies: 5)
Quote: How is DTN building @ES# bars ahead of the official US time per the USNO? At times the bars are almost 45 seconds ahead of the 'real' time. IQ assigns timestamps one period ahead of time, its the same data but different way of using timestamps, you can check my thread on a related topic here: http://forums.iqfeed.net/index.cfm?page=topic&topicID=2834--- Original message by Johnny Abodhi on Dec 28, 2010 08:33 AM Believe me, I tried many vendors, IQ is the best :)
Data and Content Support »
Tick data discrepancies between Streaming Level-I quotes and Historical tick data Dec 22, 2010 12:58 PM
(Total replies: 7)
The fact that the "Total Volume" field is matching for tick to tick on 1) streaming level-I quotes and 2) historical tick data, implies that the particular tick record I explained above must have been a legit tick received in streaming data but later got busted by the exchange. If there is no way to find corrections for such busted trades in streaming level-I data, I am thinking of implementing the following workaround. Run HIT command at regular intervals (say 1 min), and cross check total volume calculated from streaming level-I tick data with the total volume received from HIT command, if they don't match then reprocess tick data through historical data port (HTT command) for that interval, which seem to be the correct data. I think the workaround won't impact performance or bandwidth since it involves simple HIT command for one record per minute per symbol. DTN_Steve, DTN_Jay - please let me know if there is no way to find these busted trades other than implementing the workaround. Thanks Brgv
Data and Content Support »
Tick data discrepancies between Streaming Level-I quotes and Historical tick data Dec 21, 2010 06:37 PM
(Total replies: 7)
Hi, I see data discrepancies between actual trades (t-records) coming in Streaming Level-I quotes and the same data retrieved via Historical tick data (HTT command). For symbol SPY there was a trade reported on Streaming Level-I port with execution date & time 2010/12/21 11:03:19t with current volume 410000, and total volume 30526325 (please see the record marked with an arrow on the right side of the attached screenshot). The same tick record is not reported on Historical tick data service (please see data on left side of the attached screenshot). All other records match perfectly well except this one trade with huge volume. I cross checked with TOS, this trade is not included in their charts. I get couple of records like this every day, especially for the symbol SPY. Am I missing something? Are these trades got busted by the Exchange and I am supposed to find it out through other records in Level-I stream? Please help! Thanks Brgv
Data and Content Support »
OHLC-V calculated from Tick Data Jun 28, 2010 08:27 PM
(Total replies: 1)
Relationship between tick data delivered through HTT command and OHLC-V data delivered through HIT command - this is what I observed: Tick data from 10:05:00 EST to 10:05:59 EST is matching with OHLC-V values for 1 minute bar at 10:06 EST Isn't this tick data supposed to be used for 1 minute bar at 10:05 and not the bar at 10:06 EST? Here is an example: I requested tick data for the instrument QQQQ through HTT command for time interval from 2010/06/25 10:05:00 to 10:05:59 EST, then I calculated OHLC-V values from the tick data: Open = 45.31, High = 45.34, Low = 45.30, Close = 45.33, Volume = 323,409. These OHLC-V values calculated from tick data are matching with the values delivered through HIT command for 1 minute bar at 10:06 EST, and not the one at 10:05 EST. Third party charting applications (like TOS), are showing the same values for the 1 minute bar at 10:05 (I am not sure if it is appropriate to attach a screenshot from other vendors, new user here, not familiar with the forum rules; but anyway attaching it here :) OHLC-V values delivered through HIT command for other time intervals (like 30 minute) show the same relationship (like the tick data from 10:00:00 to 10:29:59 is matching with the values delivered for 30 minute bar at 10:30) What is the correct way to calculate OHLC-V? Use tick data from 10:05:00 to 10:05:59 to calculate the 1 minute bar at 10:05 or 10:06? |
|||||||||||||||||||||||