Hello,

I am new to the IQFeed ,my goal is to download historical tick data in order to construct 1-30 second hi-lo bid-ask bars for all avalible low spread stocks.

I would be interested in 3 elements per tick, {timing(in ms since epoch) , bid , ask} , and if possible also downloading only those without additional data.

From what i have understood from the customer support is that tick data goes back 180 days and is avalible for all instruments.

Would reconstructing hi-lo bars from this data be accurate for example to timeframe of 5 seconds?

Where can the api documentation be found for setting up historical tick data connections?

Are there some sort of limitations to limit historical data download speed?
Concurrent socket connections limitations per api key?
Limits on requests per some timeframe?
Edited by dd on Jun 16, 2020 at 07:17 PM

Answers to your questions:

Online documentation of the IQFeed API can be read at http://www.iqfeed.net/dev/index.cfm?login=login. You will need to login with your website username and password, which you received when you subscribed to the API product. If you don't know it, that URL has a "send me my password" link. You just need to enter your email address. If you still can't retrieve it, contact IQFeed support.

The most basic way to build historical bars is a history command, as per https://www.iqfeed.net/dev/api/docs//HistoricalviaTCPIP.cfm. What you probably want is an HIT command. This allows you to specify a symbol, interval, start/end date/time, and get a list of all intervals in that range. This will return Timestamp,High,Low,Open,Close,Volume,Period Volume.

If you want to collect historical bars and gather new bars as they come in, the BW command works similarly.

Yes, tick data generally goes back 180 days. Minute and daily data goes back further.

There is no limit to concurrent connections, provided they all come from the same computer. To have concurrent connections from different machines would require multiple IQFeed login IDs.

There can be 15 history requests active at one time. "Active" means the request has been sent and the data has not been completely returned yet. If you are requesting large amounts of history for a large number of symbols, you might have to space your requests out a little. But most requests process so quickly this isn't an obstacle.

If you are doing any kind of live "watching" of a symbol, you may only watch up to 500 symbols at a time, unless you pay an additional fee to view more.

There are no per-time period maximums on the total number of historical requests you make.

---

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

Hi,

If keeping 10-15 connections(or what appears most optimal for throughput) and requesting new histrorical data right after previous response is received.
Would it be fine or still need to space out like you mention?
If too many data requests are sent what will happen?

The HIT command you mentioned,
Is it possible for both bid and ask?

What download speeds have been achieved by clients that are after historical data if utilizing multithreaded client and no client sided bottlenecks?

If downloading for example 5-10% of IQFeeds database,tick data of low spread stocks (probably most active and dense with data).
Approximately how much data would it generate for storage or in networking packets?
I understand space is heavily dependant on data format but estimate is good enough.

To avoid reinventing the wheel, Are there historical data downloading client programs already avalible that are optimized for speed and generate readable format files to download IQFeeds tick data for list of instruments?
Edited by dd on Jun 17, 2020 at 09:44 AM

The maximum number of simultaneous history requests is tied to the loginID, not the connection. So having 10-15 multiple threads under the same loginID will not increase that limit.

Only tick-level historical requests will return Bid and Ask.

I can't really comment on end user download speeds, because that depends largely on how much data you're downloading, time of day, internet connection, and other factors. In general, best practices are to have different threads for retrieving data from the API, converting it to your desired form, and then acting on it. Having multiple connections to the IQFeed API can help also.

The timestamps in the data are exchange timestamps, so you can use those to determine your total transit time.

DTN has general sample code in C, C#, Java, and Visual Basic at iqfeed.net, and we are aware of several Python repositories around GitHub. But I'm not aware of any such code for that specific purpose.

---

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

For the benefit of anyone who happens across this thread, note that on Dec. 22, 2020 DTN has changed the throttling mechanism for historical data queries: instead of the old limit on the number of concurrent connections, the new limit is on the number of queries within a rolling 1-second window (50 queries/sec).

References:

• http://forums.iqfeed.net/index.cfm?page=topic&topicID=5832
• http://forums.dtn.com/index.cfm?page=topic&topicID=5831

There is currently no known throttling limitation on other types of IQFeed queries (non-historical).

---

Yair Altman
IQML - IQFeed-MATLAB connector
https://UndocumentedMatlab.com/IQML

I am not a DTN employee; my post reflects my personal opinion

Real-time bars are based on tick data on the spread chart, whereas historical bars are based on minute data. This difference is that tick price movement data inside the bar is not included in historical bars. This is a feature of the spread chart calculation method.
I purchased deal tracking software(https://revenuegrid.com/sales-pipeline-visibility/) to track all the charts even more accurately. The notification server processes the data received in real-time, while the server processing the graph data can also work with historical data. Thus, I am closely following the dynamics of investments.
Edited by vsdera on Apr 18, 2022 at 03:58 PM