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)

"The service is great, I see a noticeable improvement in my volume profiles over [broker]'s data feed" - Comment from Larry
"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
"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 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
"If you are serious about your trading I would not rely on IB data for serious daytrading. Took me a while to justify the cost of IQ Feed and in the end, it's just a 2 point stop on ES. Better safe than sorry" - Comment from Public Forum
"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
"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.
"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
"Can I get another account from you? I am tired of ******* going down so often" - Comment from George
"You have an excellent feed. Very few spikes for Spot Forex." - Comment from Public Forum Post
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: tadams
About Contact
Joined: May 7, 2004 02:04 PM
Last Post: Aug 29, 2004 10:19 PM
Last Visit: Jan 29, 2005 03:14 PM
Yahoo IM:
Post Statistics
tadams has contributed to 18 posts out of 19452 total posts (0.09%) in 5,816 days (0.00 posts per day).

20 Most recent posts:
IQFeed Developer Support » Summary Message Format Aug 29, 2004 10:19 PM (Total replies: 2)

The documentation doesn't address the last 10 fields in the summary message. Can the fields be described (and documentation updated)?


Data and Content Support » List of symbol in each sector Aug 3, 2004 11:53 PM (Total replies: 4)




Pardon the rant - I became distressed after seeing the comment that DTN knows there's a problem with the split process that is currently in production and is testing a fix. (What's the problem? Can you notify me of the change so I can be prepared to alter my historical data as you transition the change into production?)

I applaud your efforts to fix issues quickly when they're identified. My concern though is that your fixes are generally forward-looking and do not provide me with the information necessary to correct my historical data. The end-users need to know the date and time any new logic takes effect, the details of the old flaw, and the logic behind the new change. Any changes to historical logic greatly impact those of us storing data versus those using realtime data.




You can perform simultaneous requests if you spawn separate threads. Each thread should connect to port 9100 and will only receive data that was asked for within the scope of that thread. I've had as many as 15-20 threads hitting IQConnect with no problems (would advise using TCP). The only caveat: IQConnect does not detect a TCP disconnect properly - if you create threads as needed to request data IQConnect will eventually crash when it reaches ~2000 prior connections. You may be able to paste 10 or so history ActiveX controls into your application and avoid the disconnect issue, but then you lose the benefit of a compartmentalized thread.


Edited by tadams on Jul 20, 2004 at 08:49 AM

Ok, now I'm worried that I have no way to analyze the historical data I've been capturing unless I severely scrutinize each symbol that recently split.

Does IQFeed have a firm position on how splits will be handled? Personally, I vote that you dont touch it and we can use the split fields to do it ourselves.

Given that the repeated requests for a change log have been ignored, I'm becoming very nervous about trusting data. I'd **really** like to know when you guys change a single byte of logic. Believe it or not, there are folks out here who want to be able to use the data we're paying for. Please stop the casual modifications that aren't communicated to us and implement a running change log for each modification that makes it's way into production. That way, we would be able to research these topics ourselves - since the logic isn't documented elsewhere....


Data and Content Support » Possible Bad Data? Jul 19, 2004 10:08 PM (Total replies: 5)

How about this:

Is there currently a 'safe' day of the week to receive option fundamentals on? My application periodically verifies that I've captured all symbols and I just noticed that I have the incorrect dates for many symbols in my database. *argh*



If I'm not mistaken this has been highlighted a few times, but phrased as 'Number of connections not decrementing'. After I've connected/disconnected to port 9100 roughly 2000 times, IQFeed crashes, Dr. Watson-style.

Some of the TCP/IP developers (Me) have encapsulated objects that spawn a connection for specific method calls. The local 'server', IQConnect, should really be able to determine when a disconnect happens.

As a workaround, I've had to create a quite nasty middleman that monitors the health of the IQConnect process and doubles as a TCP server. My objects connect to this server to receive IQConnect 'health' messages. When IQConnect crashes (multiple times daily), my objects are broadcast a message indicating that it's down. The middleman forcefully terminates IQConnect then restarts it. When 5009 is alive again, a broadcast is sent out indicating that all is OK again.

This is particularly troubling when I'm grabbing a series of historical data. Since I have to code around UP and DOWN events, lots of extra code is required to remember how far I've gotten. On the other hand the middleman is a lifesaver for realtime watches, as my UP event populates a watch list (if IQFeed crashes, the persistent middleman forces it back up ASAP and data capture resumes with no additional coding).

Users of the ActiveX objects won't have this issue, but also cannot recover from an IQConnect crash.

In summary, this is the most critical issue I've seen as it causes IQConnect to crash in the midst of data capture daily. Hope my marketing of the topic has an effect.....

Edited by tadams on Jul 1, 2004 at 09:46 PM

IQFeed Developer Support » T Messages Gone? Jun 20, 2004 09:04 PM (Total replies: 4)

Thanks. In case an additional sample is needed, try "YHQ JS".



IQFeed Developer Support » T Messages Gone? Jun 15, 2004 10:40 PM (Total replies: 4)

Apologies, that was my error. While I'm here....

I'm experiencing issues with historical data for a few option symbols.
As an example, here's the output for 'ZQN AM' (Amazon JAN 05, Call, 65 Strike):

2004-6-8 13:40:00,2.200000,15,36,2.200000,2.200000
2004-6-8 13:40:00,2.200000,14,50,2.200000,2.200000
2004-6-8 13:40:00,2.200000,16,66,2.200000,2.200000
2004-6-8 13:41:00,2.200000,37,103,2.200000,2.200000
2004-6-9 9:36:00,2.300000,1,1,2.250000,2.300000
2004-6-10 221:196:00,1.850000,10,10,1.800000,1.900000
2004-6-10 221:196:00,1.850000,10,20,1.800000,1.900000
2004-6-10 9:56:00,1.750000,5,25,1.750000,1.800000
2004-6-10 10:53:00,1.800000,14,39,1.750000,1.800000
2004-6-10 13:43:00,1.750000,2,41,1.750000,1.800000
2004-6-14 10:34:00,1.700000,10,10,1.650000,1.700000
2004-6-15 9:39:00,1.800000,6,6,1.750000,1.800000


As you can imagine, I'm having trouble understanding timestamps in the format that they're presented on June 10. Advice?

Note that your history application example displays 221:196:00 as 9:36AM

Edited by tadams on Jun 15, 2004 at 10:47 PM

IQFeed Developer Support » T Messages Gone? Jun 15, 2004 12:03 AM (Total replies: 4)

I may be up past my bedtime, but have the T messages (time, port 5009) gone away in the most recent version? I was using this as a method to help determine things were OK.


IQFeed Developer Support » History Data for Options: returns no data.. May 31, 2004 10:34 PM (Total replies: 4)

Note to developers using TCP/IP:

The history server (9100) seems to not like spaces in symbol names. Given that this is the native IQFeed way to reference option symbols, this is a problem. A round of sniffing packets reveals that DTNHistoryLookup.dll replaces a space with an underscore prior to sending the request on to the history server. This is why I couldn't retrieve option data via TCP.

Moral of the story: even though the rest if IQFeed references option symbols like this:
"MSQ FE", you need to convert it to this "MSQ_FE" if you'd like to see history data.

Can this subtlety please be placed in the documentation?


IQFeed Developer Support » History Data for Options: returns no data.. May 30, 2004 12:29 AM (Total replies: 4)

I'm having a problem retrieving historical data for options via TCP/IP. As a test, I picked 'MSQ FE' (Microsoft June call with nice volume) and issued the following commands:

HX,MSQ FE,100;
HM,MSQ FE,1,5;

No matter which of the history commands I issue, the response is always a quick '!ENDMSG!'.

I've tried multiple symbols, etc but can't seem to get historical option data. Interestingly, the sample history applications IQFeed provides will retrieve data just fine (same symbol).

I'd gladly post source code that demonstrates the issue, but a simple telnet to 9100 will show the H commands return nothing. Help!


IQFeed Developer Support » Clients Connected not decrementing May 19, 2004 11:08 PM (Total replies: 0)

Previous versions of IQFeed did not decrement the connection count (can't vouch for any internal code/resources) within the IQ Connection Manager once a TCP/IP-based application disconnected from it. There's no real damage done unless ~2000 connections are made. At this point, the IQ Connection Monitor does the equivalent of a Dr Watson.

Unfortunately it looks like this is still hanging around in 2.3.

I've written plenty of code to try to catch IQFeed crashes and react properly. One precaution is to make a new local TCP connection for each distinct request. If the connection fails, something is wrong. I never assume a port opened much earlier is still running and available for use. The result is many connections/disconnections. This shouldn't be an issue for DTN since these connections are all internal to my PC.



IQFeed Developer Support » Version 2.3 Installation Error May 16, 2004 11:00 PM (Total replies: 7)

Answering my own question:

Using depends.exe, I listed the IQFeed DLL dependencies and manually re-registered each dependent DLL.

After I re-registered ATL.DLL all was fine.


IQFeed Developer Support » Version 2.3 Installation Error May 16, 2004 10:17 PM (Total replies: 7)

I'm receiving an error dialog at the end of the IQFeed 2.3 developer setup.exe.

Specifically, the dialog says:

The following files did not self-register or unregister:

1. C:\@APPS\IQFeed\IQ_API.DLL (Class not registered)
2. C:\@APPS\IQFeed\IQFeedX.DLL (Class not registered)

I've tried manually registering these (regsvr32) and receive the following message:

DllRegisterServer in iq_api.dll failed. Return code was: 0x80040154.
Same error code results for iqfeedx.dll.

I've uninstalled, reinstalled, rebooted between each uninstall/reinstall, installed to the default location, etc but still receive the same error. I've tried to unregister then reregister

The primary port seems to work, but the history port does not. Telnetting to results in the following:

..Error IQ_API Symbol Lookup COM OBJECT, lookup layer not available

Please help, I'm crippled..


We may be going in separate directions.. Detail follows..

For starters, overall datafeed impact: Presently your customers (including me) invoke a real-time watch on each individual option associated with an equity. Folks that are interested in option data generally use little bandwidth for those symbols as the number of 'ticks' are very low in the grand scheme of things. A tick is generated on bid/ask, OI, and actual trades.

If, for example, I wanted data on Microsoft's options I would have to perform a realtime watch on each option symbol. Needless to say that an IQFeed subscriber will quickly approach my 500 symbol limit.

Consider the number of ticks generated by the MSFT symbol itself. I estimate that is you sum all ticks generated by all child options, you'd land at a number less than a quarter of the parent's ticks.

The summary is that if you're interested in options, you essentially max out around 5 equity symbols (and use 1/50th of the bandwidth a person with maxxed out equity watches consumes).

The nature of options is that very few actual trades happen. With options, the valuable data is in the bid/ask prices. Unfortunately this data will not be available via the history mechanism and I'll have to continue real-time watches.

From a technical implementation viewpoint, it would be nice to submit a single watch request for the chain. This, in itself, is of little value because a properly motivated developer can just request the list of call and put symbols and add them his/herself.

The real value would come in terms of additional value developers could offer clients. Here's what I would really like:

- Start: Nothing watched.
- Watch a single option for MSFT (1/500 used)
- Watch a single option for XOM (2/500 used)
- Watch a second option for MSFT (2/500 used)
- Watch a Nth option for MSFT (2/500 used)

In effect, since volume is negligible the point system used to calculate number of watches doesn't penalize you for multiple watched options within a single equity.

I'd give up the above functionality in a heartbeat though if I could get this data historically.

Edited by tadams on May 7, 2004 at 04:11 PM

Oops.. Looks like I selected the correct avatar.

I understand the volume of data would be a strain on any architecture. Maybe a more reasonable wish is the ability to watch an option chain instead of each symbol.

Nice forum software by the way..


Might as well start off the wish list with this one:

If bid/ask change event data were included in the historical option data, it would eliminate my need for an all-day watch on dozens of symbols.

It has been hinted that this data will be available in the next patch..

Time: Wed April 8, 2020 11:07 AM CFBB v1.2.0 16 ms.
© AderSoftware 2002-2003