Joined: |
Nov 14, 2012 09:16 PM |
Last Post: |
Dec 3, 2017 11:52 PM |
Last Visit: |
Dec 4, 2017 07:34 PM |
Website: |
|
Location: |
|
Occupation: |
|
Interests: |
|
|
AIM: |
|
ICQ: |
|
MSN IM: |
|
Yahoo IM: |
|
|
bludev has contributed to 16 posts out of 21185 total posts
(0.08%) in 4,180 days (0.00 posts per day).
20 Most recent posts:
Were there any EMINI live tick data latency or other data related issues last Friday 1st Dec 2017 around (10:12:36 to 10:13:09) and (10:36:36 to 10:46:10) Chicago time? as we experienced lagged in receiving the tick data as well as missing 10 minutes of data.
We found that some live tick data are different from historical tick data.
Live reporting more ticks than historical. These differences occur quite often throughout the day (thousands of ticks different).
Both live and historical use the same IQFeed on the same machine.
Live Q,@ESZ17,09/18/2017,08:18:09.681,2501.75,1,298390 Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393 Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393 Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393 Q,@ESZ17,09/18/2017,08:18:21.772,2502,1,298413 Q,@ESZ17,09/18/2017,08:18:27.135,2502,1,298440 Q,@ESZ17,09/18/2017,08:18:27.135,2502,1,298440 Q,@ESZ17,09/18/2017,08:18:33.750,2502,2,298461 ... Q,@ESZ17,09/18/2017,10:40:49.321,2504,6,777536 Q,@ESZ17,09/18/2017,10:40:52.318,2504,7,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,5,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627 Q,@ESZ17,09/18/2017,10:40:55.292,2504.25,1,777748 Q,@ESZ17,09/18/2017,10:40:55.292,2504.25,1,777748 Q,@ESZ17,09/18/2017,10:40:56.993,2504,2,777772
Historical Q,@ESZ17,09/18/2017,08:18:09.681,2501.75,1,298390 Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393 Q,@ESZ17,09/18/2017,08:18:21.772,2502,1,298413 Q,@ESZ17,09/18/2017,08:18:27.135,2502,1,298440 Q,@ESZ17,09/18/2017,08:18:33.750,2502,2,298461 ... Q,@ESZ17,09/18/2017,10:40:49.321,2504,2,777536 Q,@ESZ17,09/18/2017,10:40:49.321,2504,6,777536 Q,@ESZ17,09/18/2017,10:40:52.318,2504,7,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,5,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627 Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627 Q,@ESZ17,09/18/2017,10:40:55.292,2504.25,1,777748 Q,@ESZ17,09/18/2017,10:40:56.993,2504,2,777772
Which one is correct? Is live reporting more ticks or is the historical missing some ticks?
Thanks
We found that two of our applications received some differences in the live tick data. Both application run on the same machine using the same IQFeed id (same protocol 5.0).
It seems like one received consolidated ticks and the other received expanded ticks. This happens only on certain data block (the rest of the data are still identical).
First application received the following data (consolidated ticks) ... Q,@ESZ17,09/18/2017,19:35:26.079,2502.75,3 Q,@ESZ17,09/18/2017,19:35:29.680,2502.5,88 Q,@ESZ17,09/18/2017,19:35:29.680,2502.25,237 Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,1 Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,1 Q,@ESZ17,09/18/2017,19:35:29.730,2502.5,1 Q,@ESZ17,09/18/2017,19:35:29.730,2502.5,8 Q,@ESZ17,09/18/2017,19:35:29.730,2502.5,3 Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,22 Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,7 Q,@ESZ17,09/18/2017,19:35:29.830,2502.25,1 Q,@ESZ17,09/18/2017,19:35:34.881,2502.25,3 Q,@ESZ17,09/18/2017,19:35:36.583,2502.5,1 Q,@ESZ17,09/18/2017,19:35:39.931,2502.25,10 Q,@ESZ17,09/18/2017,19:35:40.231,2502.25,22 Q,@ESZ17,09/18/2017,19:35:41.783,2502.25,1 Q,@ESZ17,09/18/2017,19:35:44.883,2502.5,1 ...
Second application received the following (expanded ticks) - we have the tick id here (last field) ... Q,@ESZ17,09/18/2017,19:35:30.091,2502.75,2,3982,1842509, Q,@ESZ17,09/18/2017,19:35:30.091,2502.75,1,3983,1842509, T,20170918 19:35:31 Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,31,4014,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4015,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4016,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4017,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4018,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4019,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4020,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4021,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,4,4025,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4026,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4027,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4028,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4029,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4030,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4032,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4034,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4035,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4036,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,7,4043,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,4,4047,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4048,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4049,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4050,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,5,4055,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,3,4058,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4059,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4061,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4063,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,3,4066,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4067,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4068,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,3,4071,1842520, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,6,4077,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,30,4107,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4108,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,87,4195,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,24,4219,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4220,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4221,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4223,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4225,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,9,4234,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4235,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4236,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,3,4239,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4240,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,3,4243,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4244,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4245,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4246,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,8,4254,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4256,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4257,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4259,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,3,4262,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,22,4284,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4285,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,12,4297,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4298,1842521, Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,10,4308,1842521, Q,@ESZ17,09/18/2017,19:35:33.727,2502.25,1,4309,1842522, Q,@ESZ17,09/18/2017,19:35:33.727,2502.25,1,4310,1842523, Q,@ESZ17,09/18/2017,19:35:33.727,2502.50,1,4311,1842531, Q,@ESZ17,09/18/2017,19:35:33.728,2502.50,8,4319,1842559, Q,@ESZ17,09/18/2017,19:35:33.728,2502.50,3,4322,1842562, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,5,4327,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,2,4329,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4330,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4333,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4334,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4335,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4338,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4341,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4344,1842639, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4345,1842650, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4346,1842650, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4347,1842650, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4348,1842650, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,2,4350,1842650, Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4351,1842650, Q,@ESZ17,09/18/2017,19:35:33.808,2502.25,1,4352,1842706, ...
Could you take a look at this issue and let us know what happen?
Thanks
We are having problem downloading historical data for the following IQFeedSymbol : "VIX.XO", "OVX.XO", "TYVIX.XO", "GVZ.XO", and "EVZ.XO". We noticed that this stopped working from 22-Apr-2017 since our program is scheduled to download once a day. We are using IQFeed ver 5.2.6.0.
The following is the message being sent and received:
>>SENT HDT,VIX.XO,20161231,,,1,, >>RECEIVE S,CURRENT PROTOCOL,5.0 E,Unauthorized user ID., !ENDMSG!,
It works fine for the tick data but not the daily data.
Please help!
Thanks
Hi Jay, any updates on this issue?
Hi guys, I do not seem to be able to locate the IQFeed symbol for the VSTOXX index.
http://www.stoxx.com/indices/index_information.html?symbol=V2TX
On most other platforms this appears to be V2TX?
Thanks Tom
Hi Mike
Many thanks for the clarification. Lets hope this is able to be resolved soon. In the meantime I will work to approximate the data aggregation % and adjust our market modelling accordingly.
Many thanks
Hi Curtis,
While I appreciate you getting back to me, I find this response very unsatisfactory.
IQFeed promotes itself as a "TRUE, tick-by-tick datafeed. This feed is completely unfiltered, allowing you to see EVERY TRADE that occurs in real-time."
Unfortunately the situation that we have here flies in the face of these claims as we are certainly not seeing every trade that occurs in real-time.
The response 'there is not much we can do to fix this' concerns me greatly and to be honest, after several years of great service from IQFeed, I am somewhat surprised.
Modelling of ASX markets by anyone using tick-based bars (such as myself) is no longer going to be receiving accurate results.
Clearly there are other 3rd party vendors out there that continue to access true tick-by-tick data from the ASX every day. I would kindly ask that you escalate this issue with the appropriate people, while it appears it is currently not currently a priority for IQFeed, it is a priority for our business.
Best Regards
Hi Curtis
I have not heard anything for a week now and was wondering if there is any update?
I am concerned that I am trading based on inaccurate data and it is costing me money. Do you know how long the data has been inaccurate for? And more importantly, when it is going to be resolved?
Thanks
Thanks for the update Curtis. It would be great to get to the bottom of this asap as it has a significant impact on our trading of this market.
Hi, I have an issue whereby the number of ticks for ASX futures data being received via IQfeed is significantly less than expected.
I have checked both the SPI and AX symbol's data and both seem to be between 20% and 30% down on the number of expected ticks, yet the total volume of contracts traded matches very closely. I am comparing IQfeed data to Tickdata.com historical tick data to which I subscribe. You can see in the screenshot attached the significant difference I am talking about with the SPI.
When I perform the same comparison between IQfeed and Tickdata.com for CME futures markets, the tick volume difference is nearly always less than 1%.
I noticed an example on the AX where multiple ticks appear to have been aggregated in IQfeed's output:
Timestamp - 13JAN2014 16:09:38 - Tick Volumes as follows: Tickdata.com: 3,14,10,1,5,5,5,8 IQfeed: 3,40,8
You will note the first and last ticks 3 and 8 are the same. Also, the SUM of all the Tickdata tick volumes in between these two ticks is 40, the same as the volume reported in the IQfeed tick.
Any help on how this issue can be resolved would be appreciated.
Thanks for this comprehensive reply, very helpful.
So having now had a chance to play with Most Recent Trade Conditions and Message Contents fields, I can see that all the spikes in my future currency data (e.g. @AD and @JY) where due to the occasional group O messages with condition 4D.
However... for crude futures QCL, these same group O messages seem to make up a substantial (~5%) portion of the data which look legitimate and without any spikes. In fact including these group O messages we are now getting much better agreement between IQ feed tick data for crude and the data we can download from TickWrite the next day.
So my question now is, is there any API for programatically finding out which symbols should include group O messages as part of normal data and which ones should exclude them? Or is this a user parameter that one would only know by trial and error?
Hi, I have recently switched to IQFeed 5.0 protocol with "S,SELECT UPDATE FIELDS,Most Recent Trade Date,Most Recent Trade TimeMS,Most Recent Trade,Most Recent Trade Size,Total Volume" This is all working fine except now occasionally I'm getting some spikes in the data which don't look like they are real trades. I'm attaching an example here (PNG file) which I've also verified by looking through IQConnectLog.txt:
Q,@ADU13,07/18/2013,07:10:36.004,0.9187,1,38571, Q,@ADU13,07/18/2013,07:30:36.418,0.9187,19,39741,
Any ideas what is causing these? Are these errors/blips in the data or some sort of "non-qualified" trade? Is there any systematic way to filter these out?
Thanks!
Hi,
We have 2 accounts registered with IQ feed which are being used on 2 production systems. Do you by any chance offer a complementary developer feed I could independently use in the development environment for testing and debugging?
Using the production accounts is not really an option in the long run because of all the disruptions during the testing phase, and it is a bit silly to register another full account when I only need to use it for a few days once every few months.
Any guidance on how to best proceed would be appreciated.
Hi,
Thanks for your reply and sorry for my late response:
Here is my attempt at a summary overview of how we use IQFeed
To connect we have an AttemptConnection() routine which roughly speaking does the following...
SocketAdmin_.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"9300")) SocketAdmin_.Send("S,REGISTER CLIENT APP,[productid]," & ID) SocketLevelI _.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"5009")) SocketLevelI_.Send("S,REQUEST STATS") listening to receive "REGISTER CLIENT APP COMPLETED" SocketLevelII _.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"9200")) SocketHistoricData _.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"9100"))
The routine is designed such that any failure or time-out at any of the above steps would return false and we try again by repeating the process at some later point. If every line executes normally then the routine return true and we assume that the connection with IQFeed is established normally and tick data must be coming through.
Any exceptions while attempting to Connect, Send, Receive or ListenForData, will trigger a ConnectionClosed() event. This event’s handler includes the following instructions:
SocketAdmin_.Close() SocketLevelI_.Close() SocketLevelII_.Close() SocketHistoricData_.Close()
to clean everything up. At this stage the IQFeed application is NOT closed and the tray icon persists. We then run AttemptConnection() asynchronously in a timed loop until a connection is established.
As I mentioned before, this often works. But sometimes if the cause of the initial disconnect is unexpected internet outage, then AttemptConnection() returns true giving the impression that everything is ok but then no data is received. So I guess one issue to look at is how to programmatically detect the problem in the first place.
Please let me know if you need me to be more specific about any of the above procedures and provide more information. Edited by DTN_Jay_Froscheiser on Nov 26, 2012 at 07:44 AM
Hi, I am experiencing an issue where IQFeed level 1 data never recovers after an unexpected internet disruption.
My application detects the initial internet outage and properly closes all port connections (admin, level 1, level 2 and history) and then starts regular attempts at reconnection until it succeeds when the internet connection is restored. But then every so often (could be intermittent) although my connection to level 1 (port 5009) is successful, I do not receive any live tick data at all, but somehow I can retrieve historical data (port 9100) without any problem.
I can confirm that this is not a problem within the application code, because of two observations 1. “Seconds since last update” in the feed status steadily increases indicating no level 1 data is being received by IQFeed 2. The IQConnect test in the diagnostics tool fails for level 1 data.
So my questions are: 1. Is this a known bug? 2. If so, are there any immediate plans to release a fix? 3. Seeing as the client application thinks it is “successfully” connected to level 1 port, is there any way of programmatically detecting the fault? (other than detecting ticks which can be a problem if the market is shut and we trade many markets in many time zones with daylight saving, so this approach can get tedious) 4. Assuming there is some way for the application to know when the IQfeed level 1 data is not working, then is there a workaround other than closing IQfeed completely and restarting again?
I am developing in Windows 7 x64 and have had this same experience with both IQFeed version 4.8 and 4.9.
Thank you in advance. Edited by bludev on Nov 14, 2012 at 10:03 PM
|
|