DTN_Steve_S has contributed to 2092 posts out of 20873 total posts
(10.02%) in 6,339 days (0.33 posts per day).
20 Most recent posts:
Quote: do you know if Kinetick connection is more reliable now? I do not keep up with their development very closely. You will need to contact Kinetick support for those discussions.
Quote: Since both are owned by DTN, Kinetick is not owned by DTN. It is owned by NinjaTrader and they do all of the support/development for it. DTN's role here is a data provider.
mrez114,
Quote: I have Kinetick data but use it with IQFeed.
This is the source of the issue. This was never intended to work and that loophole has been closed.
If you are only using your account with NT software (as intended with Kinetick data accounts), then changing your adapter settings is all you need to keep working as you always have.
If you were using your Kinetick account with other 3rd party software, then you will need a full IQFeed account to continue at the same level of service going forward.
taa_dtn, it looks like you're running 6.2.0.23. There was a bug fixed in IQFeed 6.2.0.25 relating to your description of the issue, and it most often triggers on reconnections, so you're likely correct it's related to local connection issues but it's was a bug in our code. I recommend upgrading and seeing if the issue still persists for you.
This message was posted in a secure forum.
Click here to access the topic where message was posted.
This message was posted in a secure forum.
Click here to access the topic where message was posted.
Hello all, Saturdays are our routine maintenance days. This involves server reboots and software restarts and, on occasion, can cause requests to fail. We typically try to keep it limited to the morning on Saturdays but sometimes it runs longer. Trying to avoid Saturday mornings for data downloads would be recommended if possible and keeping in mind that request failures should be expected during this time if you are working with our API.
This weekend has been a fairly large bit of maintenance compared to normal with some key infrastructure pieces getting a rare restart/reboot. I believe those would explain the news request failures in this thread. As a result, I was online yesterday morning and again yesterday afternoon verifying that things seemed to be working correctly. We have had users connected and using the system all weekend (with limited success as demonstrated in this thread during the previously mentioned saturday morning maintenance). I have not seen anything yet to indicate further issues.
If you are still experiencing problems. please contact our support group for assistance so we can help identify the issue.
Craig, can you give me a bit more detail on the timeframe you were seeing the errors? Looks like this was likely saturday sometime and/or early sunday? If so, the source of the issues was most likely standard weekend system maintenance causing a backend server to not respond or not respond quick enough to the request. OS patches/software upgrades/etc almost always happen on saturdays since the markets are closed.
This format for the data is only available back through May 21st, 2018.
You are correct. We found the same results and I was just typing up a response when you posted. All the symbols are in the system, just not getting to the chains server currently. We are still investigating an will let you know when we have a fix available. Edited by DTN_Steve_S on Feb 28, 2022 at 03:46 PM
I can replicate the issue with your request.
Here is the request that our chains app uses (pulled from the IQFeed Logfile).
CFO,@ESH22,pc,,23,1,LookupChains
It appears the server is not handling the case where you are not sending the year codes. I have alerted our server team about this but the workaround is to send that field.
-edit- Just noticed your second post. I'll take a closer look at the contracts returned. I don't believe this behavior should have changed since last week. Edited by DTN_Steve_S on Feb 28, 2022 at 11:03 AM
Sorry for the delay here.
We do not have date fields for bid/ask in the feed. As a result, you cannot be certain that bid/ask values in a summary message are from the current day (especially true if you are requesting around midnight Eastern for symbols that update across midnight). However, any update message that indicates a bid or ask update occurred (based on the Message Contents field) can safely be assumed that the date for the bid/ask is the current date (again, based on Midnight Eastern).
Hello, can you give us the exact request you are sending to the feed?
Also, is the issue still occurring? If so, does it also happen with our chains app that is included with IQFeed (the app sorts symbols by position in the return message in relation to the : field)?
This morning, I do not seem to be able to duplicate the issue.
Hello, the official release version is 6.2.0.23 currently (not 6.1). The version field in the S,CUST message also controls the IQFeed version Upgrade Nag so it has always lagged the actual release date by a bit of time to allow a small number of customers to upgrade naturally before we turn on the nag. Unfortunately, with the timing of data center move, we didn't want to have both happening at once so we are delaying the upgrade nag until after the datacenter move is complete.
However, the current version field in this message does not indicate (and never has indicated) the installed version. For example, once we update this field after the move, customers running 6.1 or older versions will still get a 6.2 version number in this field.
The installed version would either have to be pulled out of the registry (documented here: https://www.iqfeed.net/dev/api/docs//RegistrySettings.cfm) or by examining the file information of IQConnect.exe.
Note that protocols are only Major.Minor. I'm guessing you meant IQFeed version 6.2.0.5 and the protocol you are using is unknown from your post.
With that said, I am unable to duplicate this behavior except on old protocols where RequestID was not yet supported on these commands (4.9-5.1). It would appear you are using one of those older protocols.
S,SET PROTOCOL,6.2 S,CURRENT PROTOCOL,6.2 SLM LS,1,NGM,Nasdaq Global Market,5,NASDAQ, LS,2,NCM,National Capital Market,5,NASDAQ, ... SLM,TEST TEST,LS,1,NGM,Nasdaq Global Market,5,NASDAQ, TEST,LS,2,NCM,National Capital Market,5,NASDAQ, ...
S,SET PROTOCOL,6.1 S,CURRENT PROTOCOL,6.1 SLM 1,NGM,Nasdaq Global Market,5,NASDAQ, 2,NCM,National Capital Market,5,NASDAQ, ... TEST,1,NGM,Nasdaq Global Market,5,NASDAQ, TEST,2,NCM,National Capital Market,5,NASDAQ, ... protocol 6.0 is the same as 6.1 and 5.2 for this request)
S,SET PROTOCOL,5.2 S,CURRENT PROTOCOL,5.2 SLM 1,NGM,Nasdaq Global Market,5,NASDAQ, 2,NCM,National Capital Market,5,NASDAQ, ... SLM,TEST TEST,1,NGM,Nasdaq Global Market,5,NASDAQ, TEST,2,NCM,National Capital Market,5,NASDAQ, ...
Here is where it stops working (and all older protocols). This is intended.
S,SET PROTOCOL,5.1 S,CURRENT PROTOCOL,5.1 SLM 1,NGM,Nasdaq Global Market, 2,NCM,National Capital Market, ... SLM,TEST E,!SYNTAX_ERROR!,
Andrew, the 5min files are really your best bet here for that many symbols. Trying any other method will be problematic at best.
Most security types are represented in these files but not all security type/exchange groups have symbols.
The IEOPTIONS file is retrieved using exchange group 14.
-edit- switched "security type 14" to "exchange group 14"
Also, if you aren't already aware, a list of security types and listed markets/exchange groups can be retrieved from the lookup port. Edited by DTN_Steve_S on Sep 4, 2020 at 09:09 AM
This message was posted in a secure forum.
Click here to access the topic where message was posted.
This message was posted in a secure forum.
Click here to access the topic where message was posted.
This isn't something we can do immediately because it would potentially break other software that uses IQFeed on the same machine.
One of the primary features of IQFeed is that you are able to run multiple 3rd party trading apps side by side without them interfering with each other. This is largely only possible due to the per-connection based settings.
With that said, this is a fairly common request, especially from non-commercial software developers (who are frequently not using multiple apps). Unfortunately there won't be any features like this in 6.1 but we do have some ideas to make setting feed configuration easier in future versions.
The only recommendation I could give would be to first request daily (or weekly/monthly) data to find the start of data for the symbol. At that point you could craft an HIT request with an end datetime that reduces the overall amount of data you're having to process.
Also, as for updating the documentation to be more clear, the next version IQFeed has the dataDirection field described as follows:
DataDirection
- This determines which order the data is returned to you.
- '0' (newest to oldest) or '1' (oldest to newest).
- Note, this does NOT change the data that is returned. The ordering of the data is simply reversed if oldest to newest is selected
I'll look into something to address explaining a bit more about how the result sets are collected.
Confirming what Yair said here.
The [MaxDatapoints] should be thought of as a "No more than X datapoints" instead of "First X datapoints before/after..." from the API.
Also, the [DataDirection] parameter does not change the result set. It only changes the direction in which the result set is delivered.
As a result, The request HIT,AMD,60,20000101 000000,20190101 235959,3,,,0 is saying "give me all of the data from 20190101 235959 back to 20000101 000000 but no more than 3 datapoints." Additionally, HIT,AMD,60,20000101 000000,20190101 235959,3,,,1 says give me the same 3 datapoints but deliver them to me oldest to newest.
|