Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)




"There is no doubt that IQFeed is the best data provider. I am very satisfied with your services. And IQFeed is the only one that I would recommend to my friends. Now, most of them are using your product in China." - Comment from Zhezhe
"I have to tell you though that using the IQFeed API is about the easiest and cleanest I have seen for some time." - Comment from Jim
"I am very happy I changed. I love the product, but more so I am thrilled with Tech Support. You are knowledgeable, polite, pleasant and professional." - Comment from Pat
"Everything is working great ! Very impressive client. The news refreshes better and is more pertinent than the ******* feed I paid $ 100/month for. I Also like the charts a lot." - Comment from Leon
"I've been using IQFeed 4 in a multi-threaded situation for the last week or two on 2600 symbols or so with 100 simultaneous daily charts, and I have had 100% responsiveness." - Comment from Scott
"If someone needs the best quality data and backfill beyond what their broker provides at a rate that is the best in the industry, I highly recommend IQFeed." - Comment from Josh via Public Forum
"I have been using IQFeed now for a few years in MultiCharts and I have zero complaints. Very, very rare to have any data hiccups or anything at all go wrong." - Comment from Public Forum
"I'm satisfied with IQFeed. It's the most reliable and fastest quote feed I have ever used. Although I'm a resident in China, it's still very fast!" - Comment from Xiaofei
"I've been using Neoticker RT with IQFeed for two months, and I'm very happy with both of the products (I've had IQFeed for two years with very few complaints). The service from both companies is exceptional." - Comment from Public Forum
"You have an excellent product !!!!!!" - Comment from Arely
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
Viewing User Profile for: Pierre845
About Contact
Joined: Dec 18, 2018 05:43 AM
Last Post: Jun 2, 2020 08:04 AM
Last Visit: Jun 2, 2020 08:06 AM
Website:  
Location:
Occupation:
Interests:
Email: pabastouil@gmail.com
AIM:
ICQ:
MSN IM:
Yahoo IM:
Post Statistics
Pierre845 has contributed to 5 posts out of 19650 total posts (0.03%) in 576 days (0.01 posts per day).

20 Most recent posts:
Data and Content Support » Same Timestamp with different TickID Jun 2, 2020 08:04 AM (Total replies: 12)

Thanks Gary_Stephen for you input on TickIDs, a refresher on how they work is always useful, even though in this case it doesn't address what I was talking about.

Indeed in the case I explained, it would actually be the opposite, as it looks as if the two trades across the Bid/Ask change should be the same one (perhaps only nanoseconds could clarify); it looks like the only reason they're different is because the Bid/Ask moved (which made the agressor code change, which I believe should stay at 2 instead of 1). As you've been working / communicating with CME, they're likely to give you an explanation.

Unless it's market making action, placing two different opposite trades (at the same time to the microsecond, but with a time hierarchy to the nanosecond), first one to get the Bid/Ask down, second to hit the Ask .. but I don't see the point.
Edited by Pierre845 on Jun 2, 2020 at 08:06 AM

Data and Content Support » Same Timestamp with different TickID Jun 1, 2020 08:46 AM (Total replies: 12)

Thanks Stephen, so do you mean that in essence the Agressor Field is useless? indeed in that case we would just need to comapre Bid/Ask/Last Price and work it out without the need of another data field.

Nevertheless, the fact that Trade TickID 272584027 occurs at the same price AND with the same timestamp, without being bundled by CME (I understand you unbundle, which creates same TickIDs), makes me wonder if this is an actual new trade (which would make the timestamp different if we had nanoseconds - could you please check that with CME maybe?),
OR
that this is the way the CME reports trades in this case, when the Bid/Ask moves but the trade is executed at Ask in this case instead of Bid (market Makers / HFT actions?), meaning the agressor code should stay to 2 and not 1.

This happens a few times during the day (>20 times), and I find that the likelihood of two traders, one bid agressor, and one ask agressor, to place their trade at the same time (to the microsecond) WHEN the Bid/Ask moves, is very low.

Data and Content Support » Same Timestamp with different TickID Jun 1, 2020 07:01 AM (Total replies: 12)

yes, it's in column 'Symbol' of the file I uploaded: @ESH20

Data and Content Support » Same Timestamp with different TickID Jun 1, 2020 06:44 AM (Total replies: 12)

Sure, please see the attached.
It's rounded (3055.8 is actually 3055.75)

Data and Content Support » Same Timestamp with different TickID May 30, 2020 11:28 PM (Total replies: 12)

Hi All,

While in the process of analysing data for efficient storage purpose (eliminating redundant or unecessary data) I encountered occurences where there is a serie of Timestamps of same value (to the microsecond).
Within it there is the same TickID to a point (also same Bid/Ask and same agressor).
Then the TickID changes, Bid/Ask as well, and also agressor, ss follows:

Seconds | Last | LastSize | Bid | Ask | TickID | Agressor
7.013979 | 3055.5 | 1 | 3055.50 | 3055.75 | 272584026 | 2
7.013979 | 3055.5 | 1 | 3055.50 | 3055.75 | 272584026 | 2
7.013979 | 3055.5 | 1 | 3055.50 | 3055.75 | 272584026 | 2
7.013979 | 3055.5 | 1 | 3055.25 | 3055.50 | 272584027 | 1 <---------

1. So Bid is hit 3 times - and I believe it's unbundled data hence the same TickID,
but how come at the same timestamp the bid/ask goes lower 0.25 pt, and a new buyer comes to hit the offer?

2. I was thinking .. is it the same agressor who was hitting the bid, but CME/IQfeed classify it as an offer agressor because the bid/Ask went down, and they calculate the agressor flag as 'last price at bid' or 'last price at ask' (and in this case the agressor field is useless as we can calculate it easily (redundant for data storage purpose).

3. Can it be explained otherwise if we had nanoseconds? as the timestamp might actually be different to the nanosecond?


Time: Wed July 15, 2020 11:54 AM CFBB v1.2.0 16 ms.
© AderSoftware 2002-2003