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)
"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
"I just wanted to say how happy I am with your service. I was able to download the API docs last week and I was able to replicate Interactive Brokers historical bar queries and realtime bar queries over the weekend. That was about one of the fastest integrations that I've ever done and it works perfectly!!!!" - Comment from Jason via Email
"As a past ******* customer(and not a happy one), IQ Feed by DTN is a much better and cheaper product with great customer support. I have had no problems at all since switching over." - Comment from Public Forum
"I've been using IQFeed 4 in a multi-threaded situation for the last week or two on 2600 symbols or so with 100 simultaneous daily charts, and I have had 100% responsiveness." - Comment from Scott
"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 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.
"The people at Nirvana have very nice things to say about your company and I can see why! Price and service is a potent combination." - Comment from Ed
"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
"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 noticed that ******* quotes locked up shortly after the interest rate announcement yesterday while yours stayed stable." - Comment from Ron in Utah
||Nov 21, 2005 02:10 PM
||Nov 15, 2018 09:58 AM
||Today @ 06:13 PM
DTN_Steve_S has contributed to 2052 posts out of 18822 total posts
(10.90%) in 4,746 days (0.43 posts per day).
20 Most recent posts:
Thanks for the logfile Matt.
This is a restriction of trial accounts (only 4 days of tick history and 1 year of daily data). As a result, your requests are getting converted to only request 365 days instead of 5000 behind the scenes.
I'm not able to duplicate this and, off the top of my head, I can't think of any scenario where you would be seeing this behavior.
Can you email me (to dev support) an IQFeed logfile with All Logging enabled? You can configure/enable logging in IQFeed using the Diagnostics app. Note that after running your test and saving the logfile, you will want to reduce the logging back to default levels for performance reasons.
Socket error 10060 is a timeout error on the connection from your machine to our servers.
Each request you make to the feed is handled in it's own connection to the server (Create -> Connect -> Request -> Receive -> Close).
As a result, if you're spinning through 3000 stocks, that is 3000 different socket connections to the server over the course of however long it takes you to make those requests.
We have investigated these sorts of reports a few different times over the years and we've never been able to replicate this reliably or identify a specific cause (all of our tests from both internal and external to our network have not been able to replicate).
If it's something that just recently started, you might try resetting your router/modem (most non-enterprise class hardware will occasionally hiccup under heavy connection load). Of course we are happy to help troubleshoot this with you but most of the time, since a simple re-request usually succeeds, most developers choose to simply implement that (as you have) and not worry about it anymore unless the problem gets worse.
OK, I'm pretty sure I've figured out what is going on here.
We have a maintenance process that runs right around that time in the early AM that clears the previous day's OHL values. My guess is that you caught it in the middle of that process running which is why only some of the symbols were affected.
If you startup sometime after 4AM eastern, you should be safe.
This sounds like the intended behavior of the feed. The client app on your machine is designed to disconnect and shut down if it isn't in use and it does an ICMP ping to the servers as part of it's shutdown process. As a result, the ICMP failure error message isn't the cause of the shutdown.
If you want to keep the app running, you have to maintain a connection to it.
Hello, sorry for the delay responding here.
I'm not seeing this same behavior currently (~6:45AM Eastern). Can you provide some specific examples of this?
In your example, All three sets of fields (Last, Extended Trade, and Most Recent Trade) will reflect the last trade price of 2500.00.
We have separate fields (Settle and Settlement Date) to display the settle information in streaming data. The settlement price is copied to the Close field but never the trade fields.
Message Contents on a summary message isn't very useful since summary messages populate all fields and the purpose of Message Contents is to tell you what was populated in the message.
Edited by DTN_Steve_S on Nov 1, 2018 at 08:55 AM
In the streaming Level1 feed, the "Message Contents" field will contain an 's' when settlements are sent. For all trades, this field will contain a 'C', 'E', or 'O'.
The same logic is true for Trades in historical data retrieval but the name of the field is "Basis for Last" in tick data requests (and settlements are marked with an 'S' instead of 's'.
The difference between the series of trade identification fields for "Last" and "Extended Trade" is that extended trades also include some FormT trades. As a result, you are correct that for Futures, those fields will contain the same values.
Edited by DTN_Steve_S on Nov 1, 2018 at 08:56 AM
Hello, we are continuing to monitor and make changes to address this issue. Friday was particularly bad since we had several different issues contributing to make the problem worse. We made some configuration changes on our servers over the weekend and continue to actively work with our providers to get the issue resolved.
Hello, I have updated the documentation to correctly note the limitations in the code (as detailed in my above post).
Unfortunately, the Streaming Bars functionality cannot be used to create daily bars. The custom Interval bar historical data (even without streaming bars) is limited to less than 1 day as the maximum interval. We have a daily historical bar lookup to service that purpose (just not available on the streaming bar port).
altmany, you mentioned in your post that a request used to work better until recently. Can you clarify what specific change you are referring to? As far as I can tell, this code hasn't changed since it was introduced. The documentation update that you noticed recently did not change behavior but was simply an (failed) attempt to document the existing behavior.
Sorry for the delay answering this.
Yes, corrections are applied to historical data (daily or otherwise).
Unfortunately, there is no notification when this happens.
I have confirmed that these extra limits are on the streaming bars implementation.
The limits that were updated recently apply to Historical data requests but streaming bars adds the extra limitation on time series bars where the only valid interval values are:
All valid values < 300 (5min).
All values between 300 and 3600 must be divisible by 60 (so only multiples of 1-minute bars).
Only 3600 (1hr) or two hour (7200) bars.
I'll get the documentation updated to reflect this for now and discuss with our server/product people about the necessity of these extra limits for the future.
I don't believe there is another way to do this.
When you don't specify an end date/time, the servers use the time of the request. The servers also always work backwards in time to service the request. As a result, the servers simply find the first X datapoints that meet the criteria of the request and then stop processing data.
You will have to calculate the end time instead.
Hello, it looks like your account is not authorized for these symbols. These contracts are on NYMEX which requires an extra authorization for delayed data.
If you login to your account on our account management portal here ( https://myaccount.dtn.com/storefront/login ), you can add those auths to your account and the requests should start working within a couple minutes.
hunter, I'm having some issues finding information about this issue from 18mo ago and Tim is out of the office today (I'll chat with him tomorrow when he gets back).
Just to confirm this actually is the same issue. Can you give me an example request/symbol where this is happening for you?
Thanks for the feedback!
We will get these issues added to our issue tracker for future development efforts and as you said "keep working".
I noticed in our logs that you are using the first build of IQFeed 6.0. Although it won't address all of your issues, I do recommend upgrading to the latest build on our website. The issue this build will address is the news app not displaying headlines on initial load (but the other scaling issues remain). There are also many other smaller enhancements to the apps and fixes for stability after lost internet connection.
There are a couple changes to that file that could affect the reliability of the code (I am unable to tell since the changes call functions that aren't included). However, by modifying the same example app to adding a simple re-request loop that triggers when the ENDMSG is received, I was able to cycle through ~27K requests without error before I stopped it.
I'm not discounting the idea that the example code might have a bug in it that causes this. The example code is designed to simply demonstrate the communication and isn't very robust. Of course it is also possible that it could be a bug in the feed itself although that would be much less likely.
My recommendation to continue troubleshooting would be for you to examine the calls to BeginReceive and EndReceive to make sure they are always paired correct. For every call to BeginReceive, there should be exactly one call to EndRecieve and it should happen before the next call to BeginReceive.
I would also add an extra Array.Clear on the socket buffer array before calling EndReceive just to be 100% sure that any data you are processing is new off the socket instead of somehow leftover from the previous read.
You might also want to turn on logging in IQConnect (you can do this via the diagnostics app) to see what the feed is actually sending and compare this to what your app is receiving. Unfortunately, the logging in IQConnect will certainly affect performance of the feed and will likely result in a very large text file so it could be troublesome to work with.
Edited by DTN_Steve_S on Apr 27, 2018 at 01:48 PM
Hello, this is almost certainly a case of either not properly dealing with partial messages you read off the socket or not properly clearing resources between requests.
By "partial messages", I'm referring to when you read from a socket into a buffer, there is no guarantee that the last characters read will be at a message break which means you have to save off the partial message you received and prepend it to the beginning of the data on the next socket read.
Henry, I sent an email to your registered email address with this information.
Feel free to reply to that email if you need additional information.
In that case, I would try splitting to up to 2 connections with 150 symbols each or 3 connections with 100 symbols each and see if the problem goes away.