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)

"Thank you so much - awesome feed, awesome service!" - Comment from Greg via Email
"Very impressed with the quality of your feed - ******* is a real donkey in comparison." - Comment from A.C. via Email
"I cannot believe what a difference it makes trading with ProphetX!" - Comment from Bruce in Los Angeles
"You have an excellent product !!!!!!" - Comment from Arely
"I'm very glad I switched to IQFeed. It's working perfectly with no lag, even during fast market conditions." - Comment from Andy via Email
"Awesome response, as usual. It is a sincere and refreshing pleasure to do business with DTN, compared to your competition." - Comment from Ryan
"If you want customer service that answers the phone, your best bet is IQFeed. I cannot stop praising them or their technical support. They are always there for you, and they are quick. I have used ****** too but the best value is IQFeed." - Comment from Public Forum
"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 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
"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
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
Yahoo IM:
Post Statistics
Pierre845 has contributed to 5 posts out of 19646 total posts (0.03%) in 573 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?),
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: Sun July 12, 2020 8:50 PM CFBB v1.2.0 16 ms.
© AderSoftware 2002-2003