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)




"I would just like to say that IQFeed version 4 is running very well and I am very happy with its performance. I would also like to extend a big thanks for the fast and efficient help that I always receive. My questions and concerns are always addressed promptly. Way to go!" - Comment from Josh in CO.
"My broker in Davenport suggested I give you a try as he uses your service and says its the best." - Comment from Bill via RT Chat
"IQ feed works very well, does not have all of the normal interruptions I have grown used to on *******" - Comment from Mark
"I am a hedge fund manager here. It’s funny, I have a Bloomberg terminal and a Bridge feed, but I still like having my DTN feed!" - Comment from Feras
"I use IQ Feed, Great stuff as far as data analysis information, storage and retrieval is concerned." - Comment from Public Forum
"This is an excellent value, the system is generous (allowing for 500 stocks) and stable (and really is tick-by-tick), and the support is fantastic." - Comment from Shirin via Email
"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 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
"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
"Just a quick one to say I'm very impressed so far :) The documentation for developers is excellent and I've quickly managed to get an app written to do historical downloads. The system is very robust and pretty quick considering the extent of data that's available. The support guys have been very helpful too, in combination with the forums it's been plain sailing so far!" - Comment from Adam
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: scottladu
About Contact
Joined: Oct 8, 2004 11:57 AM
Last Post: Oct 21, 2004 08:43 AM
Last Visit: Mar 2, 2005 08:24 AM
Website:  
Location:
Occupation:
Interests:
Email: scottladu@aol.com
AIM:
ICQ:
MSN IM:
Yahoo IM:
Post Statistics
scottladu has contributed to 7 posts out of 21185 total posts (0.03%) in 7,138 days (0.00 posts per day).

20 Most recent posts:

OK, I'm sorry if I offended you, but I grew up in Chicago where a gentleman named Marshal Field came up with the concept that "the customer is always right!" And in my almost 30 years as a programmer, system analyst, database architect, etc. I have had to adhere to that concept in order to provide my users with applications that actually did what they were supposed to do.

Along with the systems themselves, my customers have always demanded good, accurate documentation, including a Data Dictionery with complete and accurate descriptions of all the data element/attributes in the system along with the SOURCE of the the element, it's points of udate, the Owner of the element, etc.

In your retort to me, you still didn't respond to my request, which is to provide this kind of complete description of the data elements I get in the real-time Emini tick feed, including any new timestams (to the second) and sequence IDs that are appently under development.

What this customer wants is to know is if there is some reason you are unable to provide me with this information, or if I haven't made my request clear.


Quote: I would like to request that any answer or response made to this post includes, as I do, the phrase "Originating Exchange Generated" in front of the various tick data attributes under discussion. "Originating Exchange Generated" means the attribute value was determined by the exchange where, and as, the specific trade occurred, and was formatted into the tick record that was then distributed to various subscribers (in this case DTN).

In the past, I have been told by technical people at more than one "feed provider" (including DTN!), that the tick timestamp (only to the minute) was generated by the "feed provider" itself when the tick record was RECEIVED BY the "feed provider" and that is did NOT represent the 'Originating Exchange Generated" timestamp! I was astounded that a "feed provider" would even consider re-selling such a mixed bag of information.

So, I ask again, will the "new" tick timestamps down to the second, and the new tick sequence that Sasha wants (I agree this is very valuable as well) be defined as:

Originating Exchange Generated Tick Sequence ID
Originating Exchange Generated HH:MM:SS Tick Timestamp

Is this true? (Of course, I assume all the other tick information, price, bid, offer, volumes, sizes, etc are also the Originating Exchange Generated data as well.)

I would really appreaciate a definite, specific, "for the record" answer to this. If I have not made this question clear enough or you haves any doubt about what I mean, please respond by asking me to rephrase or clarify.

Thank you,
--- Original message by scottladu on Oct 16, 2004 10:15 AM
Scott,

I am not sure if we store that info in our ticker, but we will check. We may be able to make this available as a field, but it won't be stored in historical/tick data. Most (or, all that I know of) don't provide this field because for storage in internal systems you want a consistent timestamp relatively. None of the exchanges are 100% in sync for time. They are always at least a second or more off from each other. This is why I say looking at an exchange timestamp and ours doesn't give you a good idea of true lag.
Jay Froscheiser
DTN Market Access, LLC.


Mr Froscheiser.

With all due respect, did you carefully read my post? First of all, I discussed TWO fields and you only refer to "...a field." I know which ones I was talking about; which one did you mean (and I would REALLY appreciate it if you humored me and actually used the full descriptive names that I used so that you don't keep confusing the issue).

I will try to make this clear again. What I, and I believe a number of other CUSTOMERS want is, the ORIGINATING EXCHANGE INFORMATION for both timestamps AND sequences (and all the rest); that's what I'm PAYING for and that's what I EXPECT. What I don't want it yours, or any other vendor's, "editorializing" about what information YOU think I need... I KNOW what I need! And if you are not providing the ORIGINATING EXCHANGE INFORMATION for ALL the data fields, then I believe you are violating our agreement.

I am now requesting a full, comprehensive definition, including the source and processing rules, for ALL the fields I am now PAYING TO GET IN REAL TIME from the CME on the Emini contracts. If I have not been getting the full and complete CME ORIGINATED data for the last few years, I may just feel entitled to a refund! Seriously, I am willing to work with you on this, but you've got to 'fess up on your side. Either you're doing it right or you're not; which is it?


I would like to request that any answer or response made to this post includes, as I do, the phrase "Originating Exchange Generated" in front of the various tick data attributes under discussion. "Originating Exchange Generated" means the attribute value was determined by the exchange where, and as, the specific trade occurred, and was formatted into the tick record that was then distributed to various subscribers (in this case DTN).

In the past, I have been told by technical people at more than one "feed provider" (including DTN!), that the tick timestamp (only to the minute) was generated by the "feed provider" itself when the tick record was RECEIVED BY the "feed provider" and that is did NOT represent the 'Originating Exchange Generated" timestamp! I was astounded that a "feed provider" would even consider re-selling such a mixed bag of information.

So, I ask again, will the "new" tick timestamps down to the second, and the new tick sequence that Sasha wants (I agree this is very valuable as well) be defined as:

Originating Exchange Generated Tick Sequence ID
Originating Exchange Generated HH:MM:SS Tick Timestamp

Is this true? (Of course, I assume all the other tick information, price, bid, offer, volumes, sizes, etc are also the Originating Exchange Generated data as well.)

I would really appreaciate a definite, specific, "for the record" answer to this. If I have not made this question clear enough or you haves any doubt about what I mean, please respond by asking me to rephrase or clarify.

Thank you,

IQFeed Datafeed Wish List » Permanent Continuous Future Contract Oct 12, 2004 07:42 AM (Total replies: 41)

I also like the sound of a "continuous" contract for the emini, etc. but I have a couple questions.

1) How is it calculated? I assume that each time the lead month rolls over, the new lead month's prices will be the real, current prices and the PREVIOUS contracts's prices will be adjusted?

2) How far back will it be available? Are you saying you will be providing some "historical" data for a year? Two years? ???

3) Will this contract include the EXCHANGE generated trade timestamp at least to the SECOND? A major concern of mine (as well as the Tick ID and Sequence Sasha mentioned)?

3) Will it include the Bid/Ask prices AND BID/ASK SIZES? Currently, when I load up a Time and Sales window the bid/ask SIZES only start loading as of the moment I open the window and then dissappear whenever I change a setting on the window..

I, like Sasha, am not trying to "blame DTN" for anything, but facts are facts. When your feed slows down I need to know IMMEDIATELY. That way the problem can be addressed whether it's on my side or yours.

Without beating a dead horse, I just want to be sure I'm saying this clearly. What I believe is the single most important piece of information needed to audit and ensure quality is the EXCHANGE GENERATED TRADE TIME DOWN TO AT LEAST THE SECOND. Anything in addition to that is great (ID, Sequence), but that needs to be the first.

Thank you.


To Tim Russel, in particular.

Do you mean that the seconds are going to APPEAR IN THE TIME COLUMN in the Watchlist and Time and Sales windows AS WELL AS coming through into my Excell spreadsheet via DDE capture of the "trade time" columns?

I have always had TWO reasons for the seconds: One was to compare the time lag represented by the difference between the exchange time stamp and the "instant" I receive the quote. I have done this on a number of occasions exactly for the purpose of determining IF iI'm getting a feed "faster than anybody else." On a number of recent occasions I have determined that I am NOT, indeed, getting the feed fastter throught DTN, but directly through my on-line broker's data feed! So, YES, mr Froscheiser, the seconds are VERY IMPORTANT to be able to do this more easily and accurately!

However, the second, and more important ,. reason is: I NEED the seconds in order to most thoroughly do HISTORICAL TESTING using the data I capture as well as the historical tick data from other vendors, including the exchanges themselves. I do this historical testing to check for ht accuracy of the data I DO get from DTN as well as to test my market trading systems which DEMAND historical data to the second, and need the REAL TIME data to the second as well in order to be able to confidently USE the signals I determine from the historical testing!

I am thrilled to hear the seconds will "soon" be included, but will they be included where I NEED them.... in the Trade Time columns?!?

DTN Satellite Products » DTN News Oct 8, 2004 12:43 PM (Total replies: 1)

I was just told by the phone support person that DTN now OUTSOURCES its new features! I need to say to Jay Froscheiser that I do NOT agree that the "new content" will help me make "even better trading decisions."

On the contrary, the two most valuble news features to me are GONE! They were:

Results of Ecconomic Reports This Week
US Event Calandar (Day, Month, Date)

These two items under DTN News/ Business, Finance, and the Economy were the only two "Pro-active" items you had. Now they are gone. Frankly, without them, your news features mean very little to me. If they weren't free, I would cancel them.

Please try to give me some encouraging news about them. On a more global level, I am very concerned about your outsourcing of this feature. Who is now providing all your news features? Can you provide guarantees as to the accuracy and timliness of the news now? Are there plans to oursources more and more of your services? How about the CME/Globex feed? Do you still receive that directly? Or are you going through one ore more other vendors for that data? I have made another post regarding the trade timestamp defeciencies, and I have a growing concern about time lags (some well over a minute) that I experienced on emini feeds, and am concerned about the direction of recent trends in the DTN services I use. Thanks for your consideration.


I believe someone mentioned the "trade timestamp" in this discussion, but if not, I'd like to ADD it. I know for a fact that the exchanges (at least the CME) send a trade timestamp that at LEAST includes the time down to the second (ins probably a full millisecond TMS) and I have NEVER understood why vendors (DTN isn't the only one) seem to feel compelled to TRUNCATE the seconds off. I am a registered user of the DTN Developer Kit and I was dismayed to discover that the seconds are not even available to a C programmer at the bit level! DTN simply "drops" that information that is passed to it from the CME (unless they are getting the CME feed from ANOTHER intermediate vendor now?).

Not knowing the exact second (or even millisecond) of when a trade was recorded at an exchange is absolutely VITAL imformation to have, especially as we move more and more to electronic exchanges and networked interfaces. If I cannot determine within ONE or TWO seconds at most that a delay has occurred, then I am at a great disadvantage in my trading.

If DTN is confident in it's datafeed, then it should be PROUD to pass on to us, the users, the FULL EXCHANGE GENERATED trade timestamp (not just to the minute) on each and every trade, bid, offer, volume stat, announcemets..... EVERYTHING.

RIght now I can only do a manual time "sync" on a minute-boundary. That is, I have to watch my PC clock (which is constantly synced with the Atomic clock) as it approaches the minute change and then see how quickly the DTN's "minutes-only" version of the timestamp catches up with real time.

I urge DTN to correct this situation globally for all its products.


Time: Tue April 23, 2024 11:08 PM CFBB v1.2.0 6 ms.
© AderSoftware 2002-2003