|
|
Home
Search
Register
Login
Recent Posts
| Viewing User Profile for: eporter | |||||||||||||||||||||||||
| About | Contact | ||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
| Post Statistics | |||||||||||||||||||||||||
|
eporter has contributed to 14 posts out of 21191 total posts
(0.07%) in 3,393 days (0.00 posts per day).
20 Most recent posts:
IQFeed Developer Support »
Bad Level 2 NASDAQ quotes today Oct 24, 2016 10:36 AM
(Total replies: 1)
I've noticed that for many NASDAQ stocks the level 2 quotes are often bad today. Some Market Makers have correct quotes, but others have junk data like you see below. These bids are far above the market price and obviously wrong. EAC and KBSF are similar. In every example I've seen, the number of cents in the quote is divisible by 4. 2,CBIO,BATS,196.76,0.,100,0,09:28:31.550,2016-10-24,52,99:99:99.000,T,F,T, 2,CBIO,BATS,196.76,0.,100,0,09:28:31.550,2016-10-24,52,99:99:99.000,T,F,T, 2,CBIO,BATS,196.76,58.88,100,100,09:28:31.550,2016-10-24,52,09:28:31.550,T,T,T, 2,CBIO,BATS,196.76,58.88,100,100,09:28:31.550,2016-10-24,52,09:28:31.550,T,T,T, 2,CBIO,BATY,196.76,0.,100,0,09:28:31.550,2016-10-24,52,99:99:99.000,T,F,T, 2,CBIO,BATY,196.76,0.,100,0,09:28:31.550,2016-10-24,52,99:99:99.000,T,F,T, 2,CBIO,BATY,196.76,58.88,100,100,09:28:31.550,2016-10-24,52,09:28:31.550,T,T,T, 2,CBIO,BATY,196.76,58.88,100,100,09:28:31.550,2016-10-24,52,09:28:31.550,T,T,T, 2,CBIO,EDGA,196.76,0.,100,0,09:28:31.551,2016-10-24,52,99:99:99.000,T,F,T, 2,CBIO,EDGA,196.76,0.,100,0,09:28:31.551,2016-10-24,52,99:99:99.000,T,F,T, 2,CBIO,EDGA,196.76,58.88,100,100,09:28:31.551,2016-10-24,52,09:28:31.551,T,T,T, 2,CBIO,EDGA,196.76,58.88,100,100,09:28:31.551,2016-10-24,52,09:28:31.551,T,T,T,
IQFeed Developer Support »
Bad historical data on 2016-09-26 Oct 3, 2016 10:21 AM
(Total replies: 2)
Possibly. For us, it appeared on the 27th, then went away on the 28th, and then came back.
IQFeed Developer Support »
Bad historical data on 2016-09-26 Sep 30, 2016 03:47 AM
(Total replies: 2)
I'm seeing problems with historical data for the day of 2016-09-26. Specifically, the volume and number of trades are both several times as large as they should be (though the price is little changed). The comparison data that I am using is what I collected on the day of 2016-09-26 through our subscription. It appears that a large number of extra ticks have simply been added to many stocks. Because the prices are reasonable, I'm wondering whether they are from a different source (such as dark pools). This isn't a huge problem for us right now. I'm simply ignoring historical data from 2016-09-26. However, it is obviously disconcerting, and my primary concern is avoiding future instances of this problem. Anyway, here's an example of the sort of difference that I'm seeing for CSBR on 2016-09-26. For what it's worth, Yahoo agrees with the volume of the existing ticks we originally received through our subscription on 2016-09-26. See https://ca.finance.yahoo.com/q/hp?s=CSBR We've seen hundreds of other, similar examples. ----------------------------------------------- Existing total: 2740 @ 1.6723 from 5 trades Received total: 19459 @ 1.6861 from 33 trades. Existing Trade ticks: 1: 40 @ 1.6900 at 2016-09-26 10:25:57.699 2: 500 @ 1.6840 at 2016-09-26 13:24:15.901 3: 2000 @ 1.6678 at 2016-09-26 15:34:40.633 4: 100 @ 1.6900 at 2016-09-26 15:51:23.654 5: 100 @ 1.6800 at 2016-09-26 15:58:31.004 Received Trade ticks: 1: 1500 @ 1.6900 at 2016-09-26 10:24:16.996 2: 360 @ 1.6900 at 2016-09-26 10:24:42.978 3: 4200 @ 1.6900 at 2016-09-26 10:25:57.697 4: 40 @ 1.6900 at 2016-09-26 10:25:57.699 5: 100 @ 1.6800 at 2016-09-26 10:31:28.776 6: 500 @ 1.6900 at 2016-09-26 10:31:59.256 7: 100 @ 1.6900 at 2016-09-26 10:37:40.586 8: 100 @ 1.6900 at 2016-09-26 10:49:56.054 9: 300 @ 1.6900 at 2016-09-26 10:53:41.505 10: 100 @ 1.7000 at 2016-09-26 11:07:56.745 11: 150 @ 1.6993 at 2016-09-26 11:14:53.401 12: 105 @ 1.6993 at 2016-09-26 11:15:44.908 13: 2000 @ 1.6990 at 2016-09-26 11:34:55.999 14: 100 @ 1.7000 at 2016-09-26 11:34:57.709 15: 1000 @ 1.6990 at 2016-09-26 11:37:29.280 16: 400 @ 1.6990 at 2016-09-26 11:37:29.283 17: 600 @ 1.6990 at 2016-09-26 11:37:29.298 18: 100 @ 1.7000 at 2016-09-26 11:50:43.276 19: 1400 @ 1.6900 at 2016-09-26 12:15:50.407 20: 600 @ 1.6900 at 2016-09-26 12:15:51.046 21: 100 @ 1.6800 at 2016-09-26 12:15:57.510 22: 300 @ 1.6691 at 2016-09-26 12:21:16.732 23: 104 @ 1.6800 at 2016-09-26 12:44:07.688 24: 100 @ 1.6900 at 2016-09-26 12:49:00.555 25: 100 @ 1.6900 at 2016-09-26 13:08:46.527 26: 500 @ 1.6840 at 2016-09-26 13:24:15.901 27: 2000 @ 1.6600 at 2016-09-26 15:31:00.252 28: 2000 @ 1.6678 at 2016-09-26 15:34:40.633 29: 100 @ 1.6900 at 2016-09-26 15:36:08.053 30: 100 @ 1.6900 at 2016-09-26 15:41:23.592 31: 100 @ 1.6900 at 2016-09-26 15:48:23.529 32: 100 @ 1.6900 at 2016-09-26 15:51:23.654 33: 100 @ 1.6800 at 2016-09-26 15:58:31.004
IQFeed Developer Support »
Random symbol not found errors with depth data Jan 20, 2016 07:05 PM
(Total replies: 9)
Tim, We haven't seen any changes to the behavior of L2 data this week. We still get the 'n' messages at the same rate and I haven't seen the NODATA market maker yet.
IQFeed Developer Support »
Bad Level 2 messages today Jan 14, 2016 11:23 AM
(Total replies: 5)
I've also noticed the problem is back. Thanks for noting that it happens with NASDAQ as well. There's a clear bug in the DTN code which produces level 2 messages where only one side is valid. The bid and ask times are swapped every single time! Here are a few examples from last week: Z,ACLZ.PK,NTFN,0.29,0.,2500,0,99:99:99.000,2016-01-06,52,05:32:12.031,T,F,T, Z,ARSC.PK,CSTI,0.,0.0002,0,2900000,07:10:37.028,2016-01-06,52,99:99:99.000,F,T,T, Z,CLWY.PK,ARCA,2.91,0.,100,0,99:99:99.000,2016-01-06,52,08:01:56.002,T,F,T, Edited by eporter on Jan 14, 2016 at 11:24 AM
IQFeed Developer Support »
Random symbol not found errors with depth data Jan 14, 2016 12:12 AM
(Total replies: 9)
I made a little progress on this by altering my code to wait for DTN to send me a 'Z' message or an 'n' message before watching another symbol. Previously my code would watch new symbols without waiting for a response to the prior requests. This worked just fine from late 2014 until Dec 28 2015. Unfortunately, it still fails 2-3% of the time, again on random symbols. Maybe something changed in the server code when the 5.2 protocol was launched?
IQFeed Developer Support »
Random symbol not found errors with depth data Dec 29, 2015 08:21 AM
(Total replies: 9)
We continue to have problems today, and once again retrying seems to work around the issue. We're watching 1250 symbols, and below is a histogram of the number of symbols that succeeded after a given number of reattempts. 302 #1 126 #2 38 #3 17 #4 7 #5 2 #6 1 #8 Remarkably, one succeeded only on the 8th attempt to subscribe it. I'm not looking to cast blame, but I can't think of anything on our end that could cause this behavior. There seems to be about 50% chance of each attempt failing, and all attempts seem to be independent. It's like we have to keep retrying until we get routed to the right server.
IQFeed Developer Support »
Random symbol not found errors with depth data Dec 28, 2015 04:20 PM
(Total replies: 9)
Retrying symbols seems to work with about 50% probability. We've seen multiple instances where a stock finally worked on the 4th attempt. Perhaps one backend server is misconfigured? It seems like there is some source of nondeterminism. We only subscribe to penny stocks, and they have worked for months without any issues until last week. We didn't change anything on our side.
IQFeed Developer Support »
Random symbol not found errors with depth data Dec 28, 2015 02:09 PM
(Total replies: 9)
We run an application which subscribes to depth data for hundreds of stocks. Recently, DTN has inconsistently been telling us that certain symbols are not found. The problem started last week, but was fine by the time trading hours began. Today the problem persisted into market hours. Our code worked for a year with no delay between the requests to watch the stocks. We added a delay today which helped a little. The symbols we get the "not found" message for are not consistent and retrying a symbol will work about half of the time. We run on Linux through WINE where DTN's depth application works consistently. Here's an example for TIGR where it worked on the fifth try. Before the '|' character is our internal timestamp. 2015-12-28 13:53:14.553014|n,TIGR.PK 2015-12-28 13:53:28.262000|n,TIGR.PK 2015-12-28 13:53:32.867000|n,TIGR.PK 2015-12-28 13:53:34.322000|n,TIGR.PK 2015-12-28 13:53:35.177002|Z,TIGR.PK,PUMA,0.17,0.195,5000,5000,08:10:07.004,2015-12-28,52,08:10:07.004,T,T,T, 2015-12-28 13:53:35.177003|Z,TIGR.PK,CSTI,0.0001,0.23,10000,2500,08:30:24.045,2015-12-28,52,08:30:24.045,T,T,T, 2015-12-28 13:53:35.177004|Z,TIGR.PK,NITE,0.17,0.18,150895,5000,13:52:01.054,2015-12-28,52,13:52:01.054,T,T,T, 2015-12-28 13:53:35.177005|Z,TIGR.PK,BTIG,0.0001,0.49,10000,2500,07:35:03.056,2015-12-28,52,07:35:03.056,T,T,T, 2015-12-28 13:53:35.177006|Z,TIGR.PK,MAXM,0.01,200.,10000,1,07:35:24.001,2015-12-28,52,07:35:24.001,T,T,T, 2015-12-28 13:53:35.177007|Z,TIGR.PK,ETRF,0.,0.,0,0,99:99:99.000,2015-12-28,52,99:99:99.000,F,F,T, 2015-12-28 13:53:35.177008|Z,TIGR.PK,CANT,0.1,0.28,5000,2500,08:30:23.012,2015-12-28,52,08:30:23.012,T,T,T, 2015-12-28 13:53:35.177009|Z,TIGR.PK,CDEL,0.107,0.2,5000,20000,13:52:01.045,2015-12-28,52,13:52:01.045,T,T,T, 2015-12-28 13:53:35.177010|Z,TIGR.PK,ATDF,0.0001,0.55,10000,2000,10:08:09.040,2015-12-28,52,10:08:09.040,T,T,T, 2015-12-28 13:59:32.507000|2,TIGR.PK,NITE,0.17,0.18,141895,5000,13:59:32.420,2015-12-28,52,13:59:32.420,T,T,T, 2015-12-28 13:59:32.612001|2,TIGR.PK,CDEL,0.107,0.2,5000,20000,13:59:32.519,2015-12-28,52,13:59:32.519,T,T,T, 2015-12-28 13:59:32.612002|2,TIGR.PK,CDEL,0.1151,0.2,5000,20000,13:59:32.519,2015-12-28,52,13:59:32.519,T,T,T, 2015-12-28 14:11:06.603000|2,TIGR.PK,NITE,0.17,0.18,106895,5000,14:11:06.519,2015-12-28,52,14:11:06.519,T,T,T, 2015-12-28 14:11:06.737000|2,TIGR.PK,CDEL,0.1151,0.2,5000,20000,14:11:06.639,2015-12-28,52,14:11:06.639,T,T,T, 2015-12-28 14:11:06.737001|2,TIGR.PK,CDEL,0.1198,0.2,5000,20000,14:11:06.639,2015-12-28,52,14:11:06.639,T,T,T, Edited by eporter on Dec 28, 2015 at 02:12 PM
IQFeed Developer Support »
Bad Level 2 messages today Sep 28, 2015 06:03 PM
(Total replies: 5)
I've looked through the logs and the problem stopped as of 9-16. I only see bad data for the 14th and 15th. Consider the issue closed.
IQFeed Developer Support »
Bad Level 2 messages today Sep 14, 2015 12:54 PM
(Total replies: 5)
Starting this morning, we started receiving badly formatted DTN messages where time cannot be parsed. This is the spec. http://www.iqfeed.net/dev/api/docs/Level2UpdateSummaryMessage.cfm The second boolean indicates that the ask is valid, but the time is clearly not. It appears to be using the milliseconds from the bid though. There are other error types that started appearing today, but this is the most common. Did something change? How should we handle the bad data? Here are a few examples: 2,GTXO.PK,BKRT,0.,8.,0,100,08:12:34.053,2015-09-14,52,99:99:99.056,F,T,T, 2,OVIT.PK,ARCA,0.,5.,0,1300,08:03:45.009,2015-09-14,52,99:99:99.009,F,T,T, 2,ABOT.PK,MICA,0.,0.749,0,1000,08:38:25.058,2015-09-14,4c,99:99:99.058,F,T,T,
IQFeed Developer Support »
Stale Level II Bid Jan 23, 2015 08:27 PM
(Total replies: 4)
This happened on the same symbol, with the same market maker on at least the 22nd as well (I didn't remember to check on the other days). So, this appears to be recurring. Eric
IQFeed Developer Support »
Stale Level II Bid Jan 20, 2015 08:20 PM
(Total replies: 4)
How often does this happen? I don't really care about this specific case, but if this sort of thing happens from time to time, I need to figure out a way to recognize it, and ignore the bad data. What do you recommend?
IQFeed Developer Support »
Stale Level II Bid Jan 20, 2015 02:21 PM
(Total replies: 4)
We're having a problem today with a stale bid in the level II data for DHOXQ. The market maker BARD is showing a bid of 0.75 while there are asks as low as 0.45. The Market Depth application as well as the data requested from the socket API have this problem. There's no indication that the bid is wrong. Any recommendations for fixing the problem? I've attached a screen capture of the Market Depth application and the raw Level II data is below. Z,DHOXQ.PK,BMIC,0.35,1.5,2500,100,06:07:29.273,2015-01-20,52,06:07:29.273,T,T,T, Z,DHOXQ.PK,BKRT,0.05,2.14,10000,100,08:13:08.984,2015-01-20,52,08:13:08.984,T,T,T, Z,DHOXQ.PK,CANT,0.33,0.45,2800,2500,11:57:41.607,2015-01-20,52,11:57:41.607,T,T,T, Z,DHOXQ.PK,MAXM,0.35,0.65,2500,1000,07:35:10.987,2015-01-20,52,07:35:10.987,T,T,T, Z,DHOXQ.PK,ARCA,0.365,1.02,8200,300,14:30:15.006,2015-01-20,52,14:30:15.006,T,T,T, Z,DHOXQ.PK,STXG,0.1,0.5399,5000,1000,10:29:35.612,2015-01-20,52,10:29:35.612,T,T,T, Z,DHOXQ.PK,GUGS,0.35,1.25,2500,150,09:30:01.535,2015-01-20,52,09:30:01.535,T,T,T, Z,DHOXQ.PK,STFL,0.0008,1.81,10000,100,08:00:01.629,2015-01-20,52,08:00:01.629,T,T,T, Z,DHOXQ.PK,MITR,0.35,1.5,2500,100,08:03:11.992,2015-01-20,52,08:03:11.992,T,T,T, Z,DHOXQ.PK,NITE,0.38,0.39,2500,13000,14:59:51.161,2015-01-20,52,14:59:51.161,T,T,T, Z,DHOXQ.PK,PUMA,0.35,0.54,2500,1000,10:22:09.058,2015-01-20,52,10:22:09.058,T,T,T, Z,DHOXQ.PK,INTL,0.,0.,0,0,99:99:99.000,2014-12-31,52,16:42:08.339,F,F,T, Z,DHOXQ.PK,CDEL,0.35,0.4499,2500,3950,14:30:36.635,2015-01-20,52,14:30:36.635,T,T,T, Z,DHOXQ.PK,ATDF,0.25,2.,2500,100,13:29:53.061,2015-01-20,52,13:29:53.061,T,T,T, Z,DHOXQ.PK,BTIG,0.0101,1.4,10000,100,07:35:02.198,2015-01-20,52,07:35:02.198,T,T,T, Z,DHOXQ.PK,VFIN,0.1,2.,5000,100,08:47:43.382,2015-01-20,52,08:47:43.382,T,T,T, Z,DHOXQ.PK,ETRF,0.,1.,0,2900,99:99:99.000,2015-01-20,52,09:30:01.539,F,T,T, Z,DHOXQ.PK,BARD,0.75,1.25,1000,100,05:32:19.173,2015-01-20,52,05:32:19.173,T,T,T, Z,DHOXQ.PK,CSTI,0.35,0.68,2500,1000,14:30:13.476,2015-01-20,52,14:30:13.476,T,T,T, Z,DHOXQ.PK,VNDM,0.1,1.02,5000,100,08:00:25.147,2015-01-20,52,08:00:25.147,T,T,T, |
|||||||||||||||||||||||||