SierraChart has contributed to 25 posts out of 18937 total posts
(0.13%) in 4,657 days (0.01 posts per day).
20 Most recent posts:
Actually, it is obvious why the request is not working. The starting date is wrong. We should have caught onto this.
There is a way that Sierra Chart manages this but it is not working in this particular case because the symbol settings for this particular symbol are not set up.
A user reported that Historical Intraday data requests fail for some spread contracts. We do not know the reason why this is happening.
Below is the Sierra Chart log for this request. This is the actual request:
Your server is returning:
HD Request # 3 | Downloading Intraday chart data for @GFH15 to the file @GFH15.scid. Service: dtn | 2016-07-12 00:23:12
HD Request # 3 | Rounding start Date-Time down to the minute: 2016-05-13 00:23:00.000 | 2016-07-12 00:23:12
HD Request # 3 | Download start Date-Time: 2016-05-13 00:23:00.000 | 2016-07-12 00:23:12
HD Request # 3 | Requesting Tick data beginning at 2016-05-13 00:23:00 US Eastern Time. Request: HTT,@GFH15,20160513 002300,,,,,1,2,5000
| 2016-07-12 00:23:12
HD Request # 3 | IQ Feed historical Intraday data request error: E,!NO_DATA!,, | 2016-07-12 00:23:13
HD Request # 3 | Error downloading historical Intraday data for @GFH15. The server returned an error. | 2016-07-12 00:23:13
Let us know what the problem is. We do not see anything we are doing wrong on our side.
Edited by SierraChart on Jul 11, 2016 at 11:27 PM
Here is an example L1 Summary quote that came thru today for QCL#:
Notice how the High=0, Low=.07, & Settle=82.70
Sometime in the recent past, we have noticed that the settlement quote has been coming thru differently for futures (i.e. ES/CL). We suspect this started when the new session times started.
What we are seeing is the settlement price comes thru correctly, but the high and low are set to bogus values (i.e. high=0.00 and low=0.07 for CL today). This is causing us some issues, and we need to understand why this has changed, and what fields are valid when the settlement price comes thru. Is there a reason that the current high/low are not properly set when the settlement comes thru? What is the best way to determine this condition?
So you are saying that there is no need to reconnect the level 2 port when we get a level 2 port system message that says "SERVER DISCONNECTED"?
The reason that we are disconnecting all of the sockets and reconnecting on a SERVER DISCONNECTED message on the Admin port is because it is a simple way for us to download any missing data due to interruption with the data feed. But there is another way we can do that. If we are in a connected state with IQ Feed, and then we see SERVER DISCONNECTED, and then we get a message indicating the server is connected on the Admin port, then we will do a backfill.
Edited by SierraChart on Dec 12, 2012 at 06:11 PM
Edited by SierraChart on Dec 12, 2012 at 06:12 PM
This is not accurate. Here is the sequence that the log indicates:
1. Everything is connected and running
2. IQ drops the connection to L2 socket
3. SC sees "SERVER DISCONNECTED" L2 System Msg <- at this point all other sockets are connected
4. SC disconnects L2 socket, and attempts to reconnect L2 socket, all other sockets are connected
5. L2 socket connection established
6. SC sees L2 Error message "Account not authorized for Level II"
7. SC gets "Not Connected" on the admin socket
8. SC now disconnects all sockets and starts a reconnect process
The problem has been confirmed but apparently it seems to occur randomly.
Here is a portion of our message log:
IQFeed: Server disconnected Level 2 data. Reconnecting. | 2012-12-11 19:03:39 (this line means that we received a level II port system message that said "SERVER DISCONNECTED")
Disconnected from IQ Feed Level 2 port. | 2012-12-11 19:03:39(we disconnect from the level II port)
Connecting to DTN IQFeed Level 2 port (9200)... | 2012-12-11 19:03:39(we connect to the level II port)
Connected to DTN IQFeed Level 2 port. | 2012-12-11 19:03:39(we are connected to the level II port)
IQFeed: Level 2 error: Account not authorized for Level II | 2012-12-11 19:03:39(level II port says the account is not authorized)
IQ Feed reports it is not connected. Will reconnect. | 2012-12-11 19:03:40(your admin port at this line is telling us it is "not connected")
Disconnecting from DTN IQFeed... | 2012-12-11 19:03:40(so we disconnect and reestablish the connection)
Edited by SierraChart on Dec 12, 2012 at 02:02 AM
We will do some more testing. I should have made it clear, that it seems this is what is happening but not totally sure because we do not log the actual admin port messages. We only reestablish the connection to IQ Feed when the admin port indicates the status is not connected. The reconnection is occurring at the time that the level 2 port is indicating that it's not authorized.
Edited by SierraChart on Dec 6, 2012 at 04:13 PM
We are noticing that when the level 2 port indicates "Account not authorized for Level II ", that the Admin port provides a System message with a status set to "Not Connected". We have not noticed this previously.
Does this make sense?
You will need to download historical intraday data as Minute data to go further back. Most likely you are downloading Tick data. After you change this setting under File >> Data/Trade Service Settings, go to the chart and select Edit >> Refresh All Intraday Data for Symbol. Additionally, in the Data/Trade Service Settings window you can control how many days of historical intraday data to download. You probably want to set that to at least 365.
We don't see any obvious problems and Sierra Chart is not filtering any data.
We think we know what the problem is and we answered the user here:
We have one customer who is reporting missing data in various Forex futures:
We cannot see how this could be an issue in Sierra Chart and we don't really know what to tell them.
We have one user who is asking about trades which are reported late and if we filter those out. In your level 1 data, do late reported trades have an old timestamp? Are there late reported trades? How do we identify them if they exist so they can be filtered.?
Here is the post from the user:
I just realized that it may not be obvious as to my conclusion being that you don't understand how we do time stamp processing. being that the trade does not contain a date but only a time, we know that the date from the timestamp last received could be off by one day. We automatically make an adjustment for that. What I would like you to do make absolutely certain that when you transmit timestamp message that the date and time values are correct and correspond to each other.
Any ideas what is causing the problem described here?
Our best guess is that your timestamp message has the prior day's time value, but the next day's date around midnight when it is sent.
Being that the problem is intermittent, I do not have any example now. We also have taken out the filtering, which means it has less of an effect on our software.
Incorrect timestamps definitely do cause problems for us and I would think they would cause problems for anyone. None of the data feeds we work with provide out of order timestamps. Your data feed has never done this until recently. I don't understand what is going on. You really need to provide timestamps that are always in order otherwise is going to be an ongoing problem. How is it that everything was OK before and now it is not? Therefore I don't really understand your answer. You are saying that the exchanges sometimes provide out of order data. However that was never the case in the past based upon what you have transmitted. Unless it was only off a few seconds.
It seems as though the time-stamp is simply incorrect but we have to look more closely.I think the timestamp is way off by more than a few seconds. But even a few seconds off is not very good. If you have been delivering data that has timestamps which are off by a few seconds, then that probably has gone unnoticed. But this problem definitely is vastly more severe than that.
We have been getting many reports from our users of problems associated with incorrect timestamps for data records in your historical intraday data. We believe this affects the tick data. However it may affect minute data as well.
The problem is there is out of order time stamping in your data base. This causes problems for us. The first problem is that if there is a time stamp for a tick record which is ahead of the time that is for, then all tick records following that record that have a preceding timestamp will get filtered out by our program. This is a special filtering to maintain the integrity of our database. One reason we do this is that if there is an invalid or out of order time stamping in the chart, this will cause our chart drawing tools to not function properly. This filtering manifests as missing data to the user.
Apparently some of your support people have been telling our customers that this is a Sierra Chart problem. It is not. It is a problem that you need to resolve on your side. We do plan to remove this filtering because of this problem. However, when we do remove this filtering users are still going to have problems using drawing tools. It will be appreciated that you promptly correct this issue and acknowledge that there is a problem. If there is not a problem, then could you identify to us why we are having a problem.
We have been telling people that you are a reliable service, but the problems that people are having are just as bad as other services.
A prompt response on this issue is much appreciated.
I see now, thank you. It would still be preferable to have the date/time formatted as YYYY-MM-DD HH:MM:SS, if that is possible.
I noticed one of the changes made in version 4.2 was the formatting of StartTime and MarketTime fields in the STATS System message. The new format of [short month][space][Day][space][hour][colon][minute][AM/PM] is much worse for parsing than the prior format of YYYY-MM-DD HH:MM:SS. I much prefer the prior formatting and ask that you may go back to that before taking 4.2 out of beta. Not only is it simpler and more efficient to parse, but it also contains the year and seconds.
I like the other date formatting changes that were made with using 4-digit years over 2-digit years.