||Jul 20, 2012 05:05 PM
||Jul 20, 2020 01:59 PM
||Jul 31, 2020 10:38 PM
aQuant has contributed to 44 posts out of 19682 total posts
(0.22%) in 2,943 days (0.01 posts per day).
20 Most recent posts:
Yes, but I am referring to real-time L1 data stream. I just pulled the raw data as received for ES, here it is for a few lines:
This indicates bid and ask of 3229.50 and 3228.75 respectively, so crossed. Note that ask size is 'frozen' at 186 and not updating. It's a case of stale ask in this case.
I am seeing this issue again today in ESU0 contract, roughly between 11:40am and 12:07pm CST. Support, could you please look into it?
I noticed a related issue. At night (~7pm CST) the L2 feed often lags the L1 feed, this is at a time when the activity is fairly low. Did anyone notcice similar? I have seen this for a few nights in a row now.
I requested this 5 years ago... but I understand the separation of L1 and L2 feeds is probably important and convenient organization of the feed data.
However, can we request the messages to contain a new field, message sequence ID, that comes directly from the exchange for both L1 and L2 update messages? This would allow the client to synchronize on their end. And you must be already parsing those from say CME in your data processing anyway. You could just pass them along (as optional field) to the client.
and tag 83 message field described as:
FIX Type: Int
Description: MD Entry sequence number per instrument update. Reset weekly.
I emailed my request to support as instructed. Thanks.
I agree, IQFeed developers should be able to handle binary protocol just as easily and it should be much more efficient to transfer to clients too. Especially with the hopefully coming soon (?) Market By Order depth protocol this would seem quite desirable to limit the number of bytes sent over the network.
I am using 18.104.22.168.
In the post above yours I didn't show where it began, I would have to look for that. I can try to locate it later.
I am definitely willing to supply a lot more information to anyone who will as a result help find a solution. But I would like to see some involvement of IQFeed support in this. I can help them nail this if they really want to solve it...
Based on the raw level1 messages it appears that one side stops updating, in the below case it was bid that got 'stuck' at 51.51, there may be other ways this happens, I didn't study them all:
It hasn't, for example today (2/11/2019) it occurred in CL, ES, 6E between 10:18-10:23am CST.
Here is an example of a few situations from yesterday where best bid is reported above best ask (MD01 updates below). This is from 1/28/2019 CLH19 instrument.
Yes, I am aware of the Bid/AskInfoValid flag. Note this line though:
which indicates end of group updates. It still has the 54.27 ask (this time all are flagged valid). This ask is definitely not valid, about 100 ticks off of correct price.
I often see incorrect/nonsensical L2 data right after a large trade takes out a few levels on the DOM (depth of market). For example, this is from CLH9 1/22/2019 at 06:01.44.16260am EST the ask price is off by almost hundred ticks for a few updates in a row. Then at 06:01:44.162895 it 'comes back' to normal.
I have other examples, where crossed bid/ask MD0x levels are reported for a number of updates (typically following a trade that sweeps a few levels). Is this something that can be fixed?
Today was particularly bad, CL and currency data (CL, 6E, 6A,6J) all had this issue for hours after 9:31am central time.
I have been seeing invalid and stale market data in various insturments (CL, ES) in the last month or so (could be slightly longer). It occurs at seemingly random times and usually lasts about 10 minutes sometimes up to an hour.
Example from today: 10:08-10:20am, 3:05-3:15pm CST in ES. Here is a snapshot of L1 updates from one of the periods:
In the above (and with my message structure) the best bid/ask data are crossed and indicating 2738.25,2733.75 for bid and ask for ES, clearly nonsensical. This same stale/invalid bid/ask info stays such for the period in question. Notice that ED above (eurodollar) is just fine as are most other contracts. This has been happening for over a month and I alerted iqfeed support to it. Initially they expressed it was due to testing MBO feed. When I contended those reasons they claimed they had some issues with CME feed. Whatever it is, this is not getting fixed and I am concerned this is not getting the priority it deserves. Any advanced developer depends on full/complete/correct data-as the feed proclaims to provide. Please correct this issue. I can provide more details if needed.
Is anyone looking into this? Looking in the past (year 2015 for example), this problem used to affect more securities but now seems to only linger still in treasury futures.
Some level2 updates are being transmitted with missing digits, resulting in non-tradable prices for US Treasury futures (cme-globex). Here is a snapshot of data 4/30/2018 data with times being EST (iqfeed original binary data)
119.4062 is not a tradable price, 119.40625 is (the 5th decimal digit is missing in the above update)
I am attaching a file from 4/30/2018 with the following structure:
cme ticker, timestamp in CST (hh:mm:ss.fffffff-to a tenth of a microsecond), bid,ask, depth (where depth is zero based, i.e. 2 means MD03 update in iqfeed terms). I scanned data from 1/1/2018-4/30/2018 and this happens daily. I can provide a full list of instances with times similar to the attached file.
Almost 2 years later, any update on this topic? Is this still on your roadmap, any closer? Thank you.
Is there any update on the above? Was it internally discussed? What is the conclusion? Thank you.