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)




"You have an excellent feed. Very few spikes for Spot Forex." - Comment from Public Forum Post
"Thanks for all of your help. Great customer service deserves to be recognized which one the reasons I've been a customer of DTN for over 10 years!" - Comment from Stuart
"Everything is working amazing now. I'm already impressed with the true-tick feed of IQFeed and it's ability to support my 480 symbol layout." - Comment from Tyler via Email
"IQ feed works very well, does not have all of the normal interruptions I have grown used to on *******" - Comment from Mark
"DTN has never given me problems. It is incredibly stable. In fact I've occasionally lost the data feed from Interactive Brokers, but still been able to trade because I'm getting good data from DTN." - Comment from Leighton
"Just a thank you for the very helpful and prompt assistance and services. You provided me with noticeably superior service in my setup compared to a couple of other options I had looked at." - Comment from John
"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
"I am enjoying the feed very much - so superior to the broker provided feed I was previously using." - Comment from George
"You are either overstaffed or people just don't have problems with your feed because customer support always answers the phone quickly." - Comment from Jay via Email
"With HUGE volume on AAPL and RIMM for 2 days, everyone in a trading room was whining about freezes, crashes and lag with *******, RealTick, TS and Cyber. InvestorRT with IQFeed was rock solid. I mean SOLID!" - Comment from Public IRC Chat
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 20376 total posts (0.02%) in 1,044 days (0.00 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: Tue October 26, 2021 4:06 PM CFBB v1.2.0 47 ms.
© AderSoftware 2002-2003