||Jan 20, 2015 02:12 PM
||Oct 24, 2016 10:36 AM
||Oct 24, 2016 12:50 PM
eporter has contributed to 14 posts out of 19452 total posts
(0.07%) in 1,907 days (0.01 posts per day).
20 Most recent posts:
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.
Possibly. For us, it appeared on the 27th, then went away on the 28th, and then came back.
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
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.
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:
Edited by eporter on Jan 14, 2016 at 11:24 AM
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?
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.
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.
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.
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.
Edited by eporter on Dec 28, 2015 at 02:12 PM
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.
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:
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.
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?
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.