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)

"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 never had DTN go out on me since switching. ******* would go down a couple times every month when I was using them." - Comment from Bryce in AL.
"I had always used ******* but for the past 2 weeks have been trying DTN IQFeed. Customer support has been extraordinary. They call just to make sure your problem hasn't recurred." - Comment from Public Forum
"I cannot believe what a difference it makes trading with ProphetX!" - Comment from Bruce in Los Angeles
"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
"I am enjoying the feed very much - so superior to the broker provided feed I was previously using." - Comment from George
"I was on the phone with a friend who uses CQG and right after the Fed announcement, CQG was as much as 30 seconds behind DTN.IQ. Some quotes were off by as much as 15-18 cents. Your feed never missed a beat." - Comment from Roger
"Interactive Brokers tick data was inconsistent, so I have switched to using DTN exclusively. It is great to no longer have to worry about my datafeed all day long." - Comment from Philippe
"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
"After all the anxiety I had with my previous data provider it is a relief not to have to worry about data speed and integrity." - Comment from Eamonn
Home  Search  Register  Login  Blogs Recent Posts

Information on Various DTN Products:
DTN IQFeed | DTN ProphetX | DTN Ag | NxCore
Follow DTN_IQFeed on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
Viewing User Profile for: DTN_Steve_S
About Contact
Joined: Nov 21, 2005 02:10 PM
Last Post: Feb 20, 2017 10:47 AM
Last Visit: Feb 23, 2017 02:12 PM
Yahoo IM:
Post Statistics
DTN_Steve_S has contributed to 2021 posts out of 17787 total posts (11.36%) in 4,117 days (0.49 posts per day).

20 Most recent posts:
IQFeed Developer Support » mfc110.dll fix Feb 20, 2017 10:47 AM (Total replies: 1)

Thanks for the post. Just for posterity, the IQFeed installer (every version for the last 10+years) should be installing these files by downloading an running the Microsoft installer for runtimes. For Linux users running IQFeed under WINE, this should still work (in our testing it has) as long as you are running the IQFeed Installer under wine as well.

If, for whatever reason it doesn't work on Linux (or windows for that matter), our official recommendation is to download and run the Microsoft installer manually (You can run it under wine if on Linux). We host a copy of the installer that we build against on our website. For the current version (5.2), use the following link:

If that still doesn't work, then the above fix will likely work for you (if on Linux).

IQFeed Developer Support » Getting Index Constituents / all US Equities Dec 28, 2016 12:28 PM (Total replies: 2)

Hello, we do not have listings of constituents available. As for your other question about getting a list of all symbols in a specific market, you have two options.

The first option is that we publish a text file of every active symbol in our system daily here:
You can parse that file to pull out whichever market(s) you need.

Alternatively, you can filter the symbol lookup requests in the API by security type or listed market (multiple markets can be sent space delimited) and just use a * wildcard in the search field to get a list from each market.

IQFeed Developer Support » ESZ16 is missing intraday back fill for 11/7 Nov 7, 2016 07:56 PM (Total replies: 12)

I can confirm this appears to be an issue in the servers. I haven't been able to identify exactly what is happening but I can duplicate the issue. I'll report this over to our server team for investigation.

For the current time, the workaround that seems to work consistently is to request the current day's data with a separate request.

IQFeed Developer Support » when busy trading,CPU usage up to 100% Oct 21, 2016 02:21 PM (Total replies: 3)

Unfortunately we don't provide a snapshot data option at this time and if implemented, the likely lower limit would be 1s.

With that said, I took a look at the code you provided and the obvious thing that jumps out at me is the use of String.Split. This function allocates a new array and a new string object for each and every field on each and every message. When dealing with potentially thousands of messages per second (possibly 10s of thousands), this is going to be very inefficient, especially since these are temporary objects and you are immediately converting the fields to binary. In order to efficiently process the feed, you need to eliminate as many of these types of temporary variables as possible in your processing.

Also, make sure you are using the dynamic fieldsets feature of the feed to eliminate any fields that you aren't interested in processing. I can't tell from the code snipit if you are using this or not but make sure you are.

IQFeed Developer Support » Need help interpreting return data format Sep 7, 2016 10:30 PM (Total replies: 6)

The derivatives history only supports interval requests which returns OHLC data. It's a bit confusing because you can request an interval of X ticks (which you have), where each message represents an interval of data containing X number of trades. However, this is not the same as a historical tick data request where each message represents a single trade with the additional information about that trade supplied. However, this is still a subset of the available fields in level 1 data since not all fields are stored historically.

To get historical tick data, you will need to issue a historical data request on the lookup port (same port your CEO request is made on). You want to issue a Tick data request which is any of the requests that start with HT(HTX/HTD/HTT). These requests documented here: All of the data returned by these requests are potentially the same but the 3 different requests allow for different types of filters.

For example: HTX,INTC1609I26,10 will give you the last 10 trades on that option symbol (in this case, the symbol has only traded twice):

2016-09-07 09:43:36.408743,9.60,5,5,8.40,9.60,5131387,C,11,20,
2016-09-01 09:30:01.004561,10.25,5,5,10.25,10.50,380528,C,11,20,

The format of the messages are documented in the above page of the documentation.

Issuing a watch request on the level 1 port of IQFeed for realtime streaming data will result in the following data being returned:
F,INTC1609I26,E,,,10.25,10.25,,,,,,,,,,,,,,,,,,INTC SEP 2016 C 26.000,,,,,,,,,,,,,,,12,2,,,2,14,09/01/2016,09/01/2016,,,,,,09/09/2016,26.000,,,100.00,0,

Note that this is the default fieldset for IQFeed protocol 5.2. You can add/remove fields from this fieldset with the dynamic fieldsets in IQFeed to your liking. In addition to the above messages, if you keep the subscription active, you will receive quote messages (start with a Q,) anytime any of the data updates.

IQFeed Developer Support » Need help interpreting return data format Sep 7, 2016 10:05 PM (Total replies: 6)

I don't think that the Streaming bars feature is what you are looking for.

IQFeed provides both realtime tick by tick data (every trade/bid/ask/etc) and Historical data. Our historical data can be retrieved as "tick", "interval", or daily/weekly/monthly bars. The tick history is every trade for the symbol and includes bid/ask price data at the time the trade occurs (no data is stored for bids/asks that occur between trades). The intervalized data provides an OHLC plus interval volume as well as the total daily volume up to that point in the day. We support tick/time/volume interval bars with the most commonly requested being time (1min/5min/15min/etc). The daily/weekly/monthly data is EOD data.

The streaming bars feature merges interval historical data requests with the realtime tick by tick data subscriptions and then streams the new bars as they complete/update. As a result, the data supplied using this feature is limited to the same data that we provide via historical data requests. This is also the reason your interval request of 1tick returned an error. Requesting 1tick isn't an interval, its just tick data which isn't supported by the streaming interval bars feature.

In order to get the type of display that you see on, you will want to go back to issuing your level 1 watch request and parsing that data for the information you need. You are correct that many of the fields will be empty when you request all fields. This is because our feed is security type agnostic and many of the fields won't apply to options data (just like fields such as strike price wouldn't apply to the underlying equity). You will have to parse the csv string that is returned and only look at the fields you want to see. alternatively, you can just request the specific fields you want (in the order you want) and the feed will deliver a message that is more to your liking. Take a look at this page for more info on selecting fields:

You might also need/want to switch to the most recent protocol (5.2) using the S,SET PROTOCOL,5.2 command prior to setting your fieldset. Some fields are only available in the newer protocols.

IQFeed Developer Support » Need help interpreting return data format Aug 26, 2016 07:43 PM (Total replies: 6)

Hello, the chains request simply returns a comma delimited list of contracts that are part of the requested chain.

The symbols are in OPRA OSI format as documented here on our website:§ion=guide&web=iqfeed&guide=options&web=IQFeed&type=stock

To get price information for the contracts, you will have to issue a request to subscribe to updates for the symbols on the Level 1 port of IQFeed (see )

RequestIDs are populated as the first field in any complete message returned from the feed for a request. In the case of chains, it will typically be all returned in a single message followed by the end of transmission message (which should also have the request ID attached).

Most of the authorization codes you list are exchanges which you have signed up to receive so those should be self explanatory. The rest are premium authorizations for News sources which you can access via the Lookup port in IQFeed (same port you are getting chains data from, you just need to send news requests instead of chains request)

Hope this helps.
Edited by DTN_Steve_S on Aug 26, 2016 at 07:44 PM

IQFeed Developer Support » IQFeed v5.2 - Request Watches Aug 10, 2016 11:24 PM (Total replies: 1)

I have confirmed this behavior in the code for the current release of 5.2.

Unfortunately, it is a bug (trades only watches are the only ones affected) and there is not going to be any workaround in the current release since that is the only command that is able to retrieve that information.

IQFeed is intended to have a single instance running on a single instance of the OS. You might be able to get this working with separate installs of wine but that would be way beyond the scope of support that we officially provide.

Keep in mind that you would also potentially be subject to duplicated exchange fees if you need data from the same exchanges on both accounts.

There is nothing in the API to retrieve this.

Any interval that is not a multiple of 60s (1min) will be limited to the same 180days that tick data is limited.

1min interval data goes back to mid 2007 for all but a couple symbols that were backfilled to 2005. We do not delete minute data so this date should never change.

IQFeed Developer Support » IQFeed Latency - NxCore Jul 25, 2016 09:52 PM (Total replies: 1)

Hello, it is true that all of our datacenters are located in or around Omaha. However, we have dedicated lines from the exchanges into our facilities to reduce latency on the incoming side. Of course IQFeed sends data out to customers over the internet and is subject to whatever routing happens between our datacenters and your machine. What this means is that our Central US location allows us to service our east coast and west coast customers equally (or at least as equally and cost effectively as we can control).

While we don't claim to be an ultra low latency feed, it is possible to collocate a machine pretty close to our datacenters (I've seen as low as about 20-25ms realistically possible). It is best to search for a datacenter in Chicago, Denver, or Dallas (in that order) since most of our internet traffic travels through those 3 cities from my experience.

Keep in mind that you would also want to take into consideration where your order execution servers are located as well since it doesn't do any good to have lightning fast signals that can't be filled before they go stale.

IQFeed Developer Support » Settle trades not chronological Jul 25, 2016 09:36 PM (Total replies: 1)

Hello, this is correct. Almost all tick timestamps are generated by the exchanges and/or data provider. We store our tick data in the order it was received and processed so it is possible for the timestamps to be out of order chronologically in our historical data. This applies to settlements as well.

Hello, sorry for the delayed response here. Hopefully you got the information from another support channel but in case you still need it (and for the forum history), for all symbols, our historical data limitations are based on the market hours of the US equity exchanges since these are the times of greatest trading activity across all supported exchanges. As such, the limits are from 09:30 - 16:30 Eastern time.

Hello, we provide a chains lookup request on the Lookup port of IQFeed where you can retrieve a current list of options symbols for a given equity symbol. Using this, you can retrieve the list of symbols which you would then subscribe to (watch) on the L1 port to retrieve the data for each symbol.

Take a look at the Chains documentation page for that request details here:

Simply put, this sort of volume analysis will not normally match up because there are reasons (depending on market/symbol) that something can adjust the volume without trading.

However, I'd bet that most of what you are seeing on AAPL are non-last-qualified trading.

Our intraday data only accounts for Last Qualified and FormT extended trading. Daily volume will include all trades.

For something like AAPL, there are bound to be a large number of oddlot trades which are not last qualified trades so the discrepancy will be large. There will like be other types of non-last-qualified trades in there as well.

If you download the Tick Data you can see all of the trades along with type and trade conditions and run detailed analysis.

Also, we do include with each interval on intraday data, the current total daily volume at the time that interval was recorded (in addition to the interval volume). This field will also include the non-last-qualified trades so you can see how the volumes differ over the course of the day.
Edited by DTN_Steve_S on May 7, 2016 at 08:38 PM

IQFeed Developer Support » Retrieve historical Tick data Mar 6, 2016 08:48 PM (Total replies: 2)

My apologies for the delayed response.

Our history servers will currently sometimes return an invalid symbol error message if there was no data available for the time period requested. We are working on addressing this problem.

As a workaround, you can safely ignore this error message and assume that the request simply returned zero datapoints.

Interval data in IQFeed is timestamped in the second following the data it represents.

As a result, your 09:31 bar represents trades from 09:30:00-09:30:59.

We also do not send incomplete bars for time based intervals unless you are authorized for realtime data for the symbol AND requesting data up to the current second while it is still trading. Any bar that lies partially within the timeframe you are requesting will be returned.

As a result, your 16:01:00 bar represents data from 16:00:00 - 16:00:59 and is included because you requested the 16:00:00 second.

IQFeed Developer Support » Developers access Mar 4, 2016 08:23 AM (Total replies: 1)

Hello, it appears your account was inactivated for some reason on the website but your productID for your software was still active in the system.

I have reactivated your website access and you should be able to login now.

Larry, this particular instance would also be explained by multiple server farms having different data. Each of our server farms operate independently from one another. This means that each has its own feed from the exchanges and separate processing.

While normally the feeds from the exchange match, problems do occur and there might be slight discrepancies in the data as processing recovers and switches from primary to backup. As a result, on the weekends we have a process that runs to consolidate historical data across all our server farms so it matches.

As a result, the following monday would be safe as far as this type of discrepancy is concerned however, the exchange can send corrections for any day at any time (we even receive corrections for data beyond our 180 day storage limit on occasion). Additionally, if our market data team determines that data is wrong, they will make corrections as needed. Unfortunately, this means that there never really is a "complete and won't change" date that I can give you.

IQFeed Developer Support » No millisecond and microsecond timestamps Feb 29, 2016 04:58 PM (Total replies: 1)

Milliseconds are only available using protocol 5.0 or higher. Microseconds require protocol 5.2 or higher.

You must set your protocol in each connection to IQFeed. In your case, since you are using COM, each instance of the COM interface is a new connection to IQFeed so you need to set the protocol in each of them.

Time: Mon February 27, 2017 6:54 PM CFBB v1.2.0 15 ms.
© AderSoftware 2002-2003