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)




"This beats the pants off CQG, I am definitely switching to the ProphetX 3.0!" - Comment from Stephen
"Thanks for following up with me. You guys do a great job in tech support." - Comment from Phelps
"Its working FABULOUSLY for me!! Holy cow...there has been so much I've been missing lately, and with this feed and Linnsoft software...I'm in the game now." - Comment from Chris R.
"I ran your IQFeed DDE vs. my broker vs. a level II window for some slow-moving options. I would see the level II quote change, then your feed update instantaneously. My broker's DDE, however, would take as much as 30 seconds to update. I am not chasing milliseconds, but half a minute is unacceptable." - Comment from Rob
"Very impressed with the quality of your feed - ******* is a real donkey in comparison." - Comment from A.C. via Email
"IQ feed works very well, does not have all of the normal interruptions I have grown used to on *******" - Comment from Mark
"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
"I like you guys better than *******...much more stable and a whole lot fewer issues." - Comment from Philip
"Everything is working great with the API. I love it." - Comment from Calvin
"I am keeping IQFeed, much better reliabilty than *******. I may refer a few other people in the office to switch as well." - Comment from Don
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
»Forums Index »NEW IQFEED FORUMS »Data Questions »timestamp in update message
Author Topic: timestamp in update message (6 messages, Page 1 of 1)

tigerzx
-Interested User-
Posts: 13
Joined: May 25, 2021


Posted: Jul 9, 2021 12:43 PM          Msg. 1 of 6
Hi, a question about the timestamp in the update(Q) messages:

How is the timestamp in the update message been assigned? Where does it come from?

Please notice in the following updates, the timestamps seems following different timelines for different symbols. For each symbol, the timestamp keeps increasing. But between symbols, they could be seconds (sometimes more than minute) apart. It looks like some delay for some symbols.

Please note the following is the output of telnet with subscriptions to several symbols. The total active subscription to IQFeed is about 350 symbols. There is also another client connecting to IQFeed at the same time to consume the data. The machine is a 8-core linux server with 32G memory.


Q,@RTY#,2308.00,1,08:52:50.896622,43,5070,2307.80,3,2308.00,1,2304.50,2308.30,2298.60,2302.00,a,01,
Q,@NQ#,14706.00,1,08:53:00.823755,43,34156,14706.00,6,14706.50,1,14704.25,14721.75,14674.50,14713.75,C,01,
Q,@NQ#,14706.00,1,08:53:00.823755,43,34156,14706.00,5,14706.50,1,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,11,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,10,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,9,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,8,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,9,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,8,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,7,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14706.00,5,14706.50,1,14704.25,14721.75,14674.50,14713.75,C,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,3,14706.50,1,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,3,14706.50,2,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,3,14706.50,3,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,2,14706.50,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.50,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.25,1,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NIY#,28620,1,08:51:42.991782,110,9701,28620,21,28625,28,28755,28755,28485,28775,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.25,2,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.25,3,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.50,3,14706.25,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.50,2,14706.25,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.50,2,14706.00,1,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NIY#,28620,1,08:51:42.991782,110,9701,28620,15,28625,28,28755,28755,28485,28775,b,01,
Q,@NIY#,28620,1,08:51:42.991782,110,9701,28620,13,28625,28,28755,28755,28485,28775,b,01,

DTN_Gary_Stephen
-DTN Guru-
Posts: 372
Joined: Jul 3, 2019


Posted: Jul 9, 2021 01:49 PM          Msg. 2 of 6
The timestamp is provided by the exchange. It is meant to indicate the timestamp that the tick occurred. It is possible for ticks with older timestamps to arrive later, as you point out. This is because the ticks come from many different sources, and they don't all do so on the same timeframe. So situations like in your example can occur, where the entire string of ticks is not in chronological order:


Q,@NQ#,14706.00,1,08:53:00.823755,43,34156,14706.00,5,14706.50,1,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@ES#,4342.75,2,08:52:53.296428,43,72578,4342.75,11,4343.00,29,4341.00,4343.75,4333.00,4342.75,b,01,

Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.25,1,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NIY#,28620,1,08:51:42.991782,110,9701,28620,21,28625,28,28755,28755,28485,28775,b,01,


Ticks for the same symbol will always be chronological, though.

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

tigerzx
-Interested User-
Posts: 13
Joined: May 25, 2021


Posted: Jul 9, 2021 02:12 PM          Msg. 3 of 6
If the timestamps all come from the exchange, then it indicates some serious delay along the path.
Note all the symbols here are from Globex. The exchange clock should be the same/synchronized. Especially instruments like ES and NQ, they are within the same market data segment.

If an event happens a minute later than another, but received before that, that means there is at least a minute delay. Is there a way we can investigate this? How to check the backlog within IQFeed?

DTN_Gary_Stephen
-DTN Guru-
Posts: 372
Joined: Jul 3, 2019


Posted: Jul 12, 2021 08:32 AM          Msg. 4 of 6
There's another detail at work in the data sample given in the original post.

You are correct that the delays are too long for the explanation I gave. The phenomenon I mentioned earlier is true, but should't make that much of a difference time-wise.

The dataset appears to be using the default set of fields from Protocol 6.1, which are:

S,CURRENT UPDATE FIELDNAMES,Symbol,Most Recent Trade,Most Recent Trade Size,Most Recent Trade Time,Most Recent Trade Market Center,Total Volume,Bid,Bid Size,Ask,Ask Size,Open,High,Low,Close,Message Contents,Most Recent Trade Conditions


With that in mind, let's look at just the @NQ# messages:


Q,@NQ#,14706.00,1,08:53:00.823755,43,34156,14706.00,6,14706.50,1,14704.25,14721.75,14674.50,14713.75,C,01,

The fields in bold face are Most Recent Trade Time and Message Contents. Message Contents will be a C, E, or O for a trade, and b or a for a bid or ask update. Most Recent Trade Time is the most recent time a trade occurred, and it includes both last-eligible and non-last eligible trades (C and O in Message Contents). Now look at the next @NQ# messages:

Q,@NQ#,14706.00,1,08:53:00.823755,43,34156,14706.00,5,14706.50,1,14704.25,14721.75,14674.50,14713.75,b,01,

This message is a bid update - not a sale. So "08:53:00.823755" is telling you the time of the most recent sale, not the timestamp of this message.

Next, we ahave:

Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14706.00,5,14706.50,1,14704.25,14721.75,14674.50,14713.75,C,01,

This is a sale, so the Most Recent Trade Time updates.

Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,3,14706.50,1,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,3,14706.50,2,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,3,14706.50,3,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,2,14706.50,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.50,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.25,1,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.25,2,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.75,1,14706.25,3,14704.25,14721.75,14674.50,14713.75,a,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.50,3,14706.25,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.50,2,14706.25,3,14704.25,14721.75,14674.50,14713.75,b,01,
Q,@NQ#,14706.00,5,08:53:00.824297,43,34161,14705.50,2,14706.00,1,14704.25,14721.75,14674.50,14713.75,a,01,

These are all bid or ask updates - not sales. The timestamp doesn't update because the most recent trade still occurred at 08:53:00.824297. These timestamps do not necessarily mean the timestamps of when this message was sent or it was received. These timestamps, as per the default protocol 6.1 setup, mean the time of the most recent trade, which could have occurred some time ago.

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

tigerzx
-Interested User-
Posts: 13
Joined: May 25, 2021


Posted: Jul 12, 2021 04:24 PM          Msg. 5 of 6
That would make sense. Thank you, Gary.

So in order to get the most recent change time, I have to listen to most recent trade time, bid time and ask time, then check which one is the latest? Is there a field for the most recent change time?

DTN_Gary_Stephen
-DTN Guru-
Posts: 372
Joined: Jul 3, 2019


Posted: Jul 14, 2021 04:21 PM          Msg. 6 of 6
If you want to know the most recent change time with no regard to what changed, then yes, you would need to watch all three of the fields.

The fields Most Recent Trade Time, Bid Time and Ask Time tell you the time of the most recent change to the price, Bid or Ask - which is not necessarily the current tick. If a Bid update occurs at 10:00:00 and a tick not containing a Bid update comes in at 10:00:01, the "Bid Time" will still be 10:00:00.

Side note: The "Most Recent" statistics include both last-eligible and non-last-eligible trades. "Last" includes only last-eligible. There is also "Extended" which covers after hours/Form T trades. So which "Time" fields you need to watch is dictated by which of those you're interested in.

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist
 

 

Time: Fri September 22, 2023 7:10 AM CFBB v1.2.0 31 ms.
© AderSoftware 2002-2003