Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Wed, 08 May 2024 17:18:37 +0000
microsecond timestamp between different Denali feed servers
View Count: 1515
| [2020-09-15 20:10:41] |
| ejtrader - Posts: 688 |
|
SC Team - If I have 2 SC instances each connected to denali feed - Is it ensured to get identical microsecond timestamps between 2 instances? Would there be an instance where Each of them is connected different feed server - are they likely to get the same data timestamp? The reason to ask this question - From one of your earlier threads you indicated this might not be the native exchange time (due to bandwidth constraints). Could you please comment? Version 2151 Available: Foundation For Millisecond/Microsecond Timestamping | Post: 231087 If they are not identical w.r.t microseconds - would they be identical to milliseconds portion (Between 2 SC instances)? Thanks Date Time Of Last Edit: 2020-09-15 20:13:55
|
| [2020-09-15 20:49:35] |
| |
|
The milliseconds would absolutely be consistent among servers and microseconds will be consistent as well but there could always be a very rare case lasting for less than a second where they might be different.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-09-15 23:01:23] |
| ejtrader - Posts: 688 |
|
You mean - on rare cases - they might differ for a second or so w.r.t microseconds but go in sync again? Thanks Date Time Of Last Edit: 2020-09-15 23:01:40
|
| [2020-09-16 10:38:44] |
| |
|
Not for more than a second. We also realize microsecond timestamps were getting transmitted out from our servers but they should not have been. Those have been removed.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2020-09-16 10:39:05
|
| [2020-09-16 13:41:54] |
| ejtrader - Posts: 688 |
|
Thank you SC Team. FYI - Today for the first time in the last week or so - there was NO lag during the market open for ES today. Usually there was 10-15 seconds lag exactly at market open (not during any other market burst events). Not sure if the change you made might have anything to do with this or not. Thanks |
| [2020-09-16 20:39:54] |
| ejtrader - Posts: 688 |
|
SC Team - If I disconnect and reconnect the subinstance - there are 2 extra records that gets added to intraday data compared to main instance. Tried it multiple times and it's consistent issue. Main instance continues to be good (compared to other standalone instance). This seems to be the problem not only to the subinstance but even for the main instance(though tested briefly). The main event that seems to cause this issue - "Historical data download" - I can demonstrate the issue if you would like. There would be 2 extra records that gets added to today's intraday data (compared with the instance where it's been running without any disruptions). This "disconnect/connect" test - you can do it even when the market is closed. Edit - Checked the delayed feed based instance as well (main instance) and it's the problem there as well. To reproduce the issue - you just need to disconnect and reconnect the feed. Thanks Date Time Of Last Edit: 2020-09-16 22:03:24
|
| [2020-09-16 22:05:03] |
| |
|
What is the Intraday Data Storage Time Unit set to in the sub instance?
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-09-16 22:11:59] |
| ejtrader - Posts: 688 |
|
Tick data - For ALL instances/sub-instances.
Date Time Of Last Edit: 2020-09-16 22:15:08
|
| [2020-09-18 03:52:16] |
| ejtrader - Posts: 688 |
|
SC Team - FYI - This issue is present even in the main instance. Using the latest version 2170 and Denali feed. Are you able to reproduce this issue? If not I can demonstrate this issue easily. It doesn't matter whether it's a live feed or delayed feed. This can be easily reproduced when you use the option disconnect/reconnect and it's a consistent issue. Thanks |
| [2020-09-18 19:56:43] |
| ejtrader - Posts: 688 |
|
BTW - I am no longer experiencing the initial data lag problems (5-15 seconds) during market open hours (3 days now). thanks |
| [2020-09-19 02:37:41] |
| ejtrader - Posts: 688 |
|
SC Team - Attached is the image of NQZ20. As you can see from the image - T&S Very last record was at 15:59:59:518000. In intraday file - there are additional records ( 4 Records - They keep increasing when you disconnect & Connect). 15:59:59:518001 15:59:59:518002 15:59:59:518003 15:59:59:518004 in Case of ES - There are 9 records in intraday file extra compared to last Time and Sales records. Would you please check and confirm as this is causing issues for various studies which expects T&S and charts/intraday files to be in sync? Edit - It appears like when there is a TS_MAKER record some how triggering the incorrect intraday record. Thanks Date Time Of Last Edit: 2020-09-20 01:12:33
|
 Sierra_TS_Intraday_MisMatch.JPG / V - Attached On 2020-09-19 02:36:23 UTC - Size: 311.51 KB - 275 views Sierra_TS_Intraday_MisMatch_ES.JPG / V - Attached On 2020-09-19 04:17:26 UTC - Size: 95.75 KB - 285 views |
| [2020-09-19 21:58:26] |
| ejtrader - Posts: 688 |
|
Uploading the video showing the same as well as the chartbook. The study inserted in Number of Trades study + Text Display for the study. All I am trying to do - disconnect/reconnect. This is the main instance. You can see for all the charts - the count increases by 1 - (Market is currently closed). Also noticed - if there is a SC triggered Historical download event (which happens periodically on its own) - Then also this count increases by 1. Only way to fix - "Delete and download" the very last day for each of the instruments. Thanks Date Time Of Last Edit: 2020-09-20 20:12:42
|
 2020-09-19 16-53-05.mkv - Attached On 2020-09-19 21:58:04 UTC - Size: 9.44 MB - 207 views V1_Test.cht - Attached On 2020-09-20 15:41:58 UTC - Size: 12.04 KB - 244 views |
| [2020-09-22 04:49:50] |
| ejtrader - Posts: 688 |
|
SC Team - Any input on this?
|
| [2020-09-22 05:28:20] |
| |
|
We are not going to be able to get to this for weeks as busy as we are. Do not post anything further here.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-09-22 05:41:23] |
| ejtrader - Posts: 688 |
|
While I understand you are busy - this is a serious potential bug you have here. Would leave it at this. This bug is not only related to manual disconnect/reconnect but even the auto triggered historical download event causes an additional record than expected - which makes the underlying data questionable. For me data not being accurate is a show stopper. Your call whether to take care of it or not. Looking at the notes for SCID - it appears like you have flaw in processing logic to consider the last trade as a valid trade - though it's been considered already. I am STUCK due this issue and you are not helping to fix this SERIOUS bug which is very easy to reproduce :( When there is an automated Historical download event is triggered or when disconnect/connect event happens - Whatever the very Last TS trade was present at that time - it gets added again though it's already part of the intraday file. This is a BUG. This erroneous records are deleted from intraday file - When "Delete and download data" is used for the very last trading session/bar. Intraday Data File Format: DateTime When writing tick by tick data to an Intraday data file, where each tick is a single record in the file, and multiple ticks/trades have the same timestamp, then it is acceptable for the Date-Time of the record to be the same timestamp as prior records. What Sierra Chart itself does in this case, is increment the microsecond portion of the Date-Time to create unique timestamps for each trade within a millisecond.
PS: Though you have asked not to be posted further this is REALLY a serious issue with NO workaround and this is a showstopper for me. Would you please review this? Just to show the magnitude of the issue - ES: Actual Number of Trades - 1024918 - With this auto triggered historical download events - Intraday file as well as number of trades is marked as 1024922 (4 record difference) - One can't really figure out where the duplicate trade is inserted into the intraday file. Date Time Of Last Edit: 2020-09-24 02:55:00
|
| [2020-09-26 16:39:18] |
| ejtrader - Posts: 688 |
|
This is SO frustrating that SC doesn't even acknowledge this as a potential bug. To maintain the accuracy across instances - it's really time consuming. It happens with all the cases below: - Live feed - Delayed feed - Main instance - Sub instance(s) - First image - incorrectly accumulated data (All this under normal circumstances - with auto triggered historical downloads which happens on it's own) - Second image - After Delete/download option is used for the very last trading day - which corrects the data. Could you kindly check on this issue? Other users - Are you NOT experiencing similar issues? Date Time Of Last Edit: 2020-09-26 16:43:30
|
| SC_IncorrectlyAccumulatedRecords_Prior_To_DeleteDownload_Tas.png / V - Attached On 2020-09-26 16:38:12 UTC - Size: 88.09 KB - 182 views SC_CorrectRecords_After_DeleteDownload_Task.png / V - Attached On 2020-09-26 16:38:20 UTC - Size: 95.68 KB - 208 views |
| [2020-09-26 22:50:06] |
| ejtrader - Posts: 688 |
|
Here it is from live feed - Today market is closed and have to deal with increasing number of trades on their own. First image captured in the morning(this is after correcting the data using delete/download option) and second image captured in the evening ( all of this under normal circumstance). So this process of incorrect data is NON-stop even if the market is not open. Main instance / live denali feed. Attached is the small portion of log from the message log - when this auto triggered. As you can see it has added 1-4 records on it's own with triggered historical download (though these records are ALREADY part of intraday file. This produces the incorrect count for a trading day. Even if the data is corrected using "delete and download" option for the last trading day - it's NOT guaranteed to stay accurate as another auto triggered historical event would again add additional intraday records making it incorrect again. No historical data client is currently set to download historical Intraday data for YM?##_FUT_CBOT. | 2020-09-26 18:05:14.304
Real-time Intraday chart data file updates started for YM?##_FUT_CBOT | 2020-09-26 18:05:14.304 Intraday chart data file opened for YM?##_FUT_CBOT | 2020-09-26 18:05:14.304 No historical data client is currently set to download historical Intraday data for MES?##_FUT_CME. | 2020-09-26 18:05:14.304 Real-time Intraday chart data file updates started for MES?##_FUT_CME | 2020-09-26 18:05:14.304 Intraday chart data file opened for MES?##_FUT_CME | 2020-09-26 18:05:14.304 No historical data client is currently set to download historical Intraday data for ES?##_FUT_CME. | 2020-09-26 18:05:14.304 Real-time Intraday chart data file updates started for ES?##_FUT_CME | 2020-09-26 18:05:14.304 Intraday chart data file opened for ES?##_FUT_CME | 2020-09-26 18:05:14.304 No historical data client is currently set to download historical Intraday data for NQ?##_FUT_CME. | 2020-09-26 18:05:14.304 Real-time Intraday chart data file updates started for NQ?##_FUT_CME | 2020-09-26 18:05:14.304 Intraday chart data file opened for NQ?##_FUT_CME | 2020-09-26 18:05:14.304 Added historical Intraday data request for NQZ20_FUT_CME to the queue. | 2020-09-26 18:05:14.304 Intraday data recording state for symbol NQZ20_FUT_CME is set to download 'Pending'. | 2020-09-26 18:05:14.304 Triggering next historical data download in queue. | 2020-09-26 18:05:14.304 Added historical Intraday data request for ESZ20_FUT_CME to the queue. | 2020-09-26 18:05:14.304 Intraday data recording state for symbol ESZ20_FUT_CME is set to download 'Pending'. | 2020-09-26 18:05:14.304 Added historical Intraday data request for YMZ20_FUT_CBOT to the queue. | 2020-09-26 18:05:14.304 Intraday data recording state for symbol YMZ20_FUT_CBOT is set to download 'Pending'. | 2020-09-26 18:05:14.304 Added historical Intraday data request for MESZ20_FUT_CME to the queue. | 2020-09-26 18:05:14.304 Intraday data recording state for symbol MESZ20_FUT_CME is set to download 'Pending'. | 2020-09-26 18:05:14.304 HD Request # 57 | Downloading Intraday chart data for NQZ20_FUT_CME to the file NQZ20_FUT_CME.scid. Service: cme | 2020-09-26 18:05:14.304 Enabling compression for file: C:\SierraChart\Data\NQZ20_FUT_CME.scid. This may take a while. | 2020-09-26 18:05:14.305 * HD Request # 57 | Download start date-time: 2020-09-25 15:59:59.000 | 2020-09-26 18:05:14.305 HD Request # 57 | Using server: ds23.sierracharts.com port 10149 | 2020-09-26 18:05:14.305 Socket (5) | Creating socket. | 2020-09-26 18:05:14.305 Socket (5) | New receive buffer size: 5242880 | 2020-09-26 18:05:14.305 Socket (5) | Connecting to IP: 216.1.90.130. | 2020-09-26 18:05:14.305 SC Futures Order Routing/Data | Received security definition for symbol YM?##_FUT_CBOT | 2020-09-26 18:05:14.553 SC Futures Order Routing/Data | Received security definition for symbol MES?##_FUT_CME | 2020-09-26 18:05:14.553 SC Futures Order Routing/Data | Received security definition for symbol ES?##_FUT_CME | 2020-09-26 18:05:14.582 SC Futures Order Routing/Data | Received security definition for symbol NQ?##_FUT_CME | 2020-09-26 18:05:14.582 SC Futures Order Routing/Data | Received security definition for symbol NQZ20_FUT_CME | 2020-09-26 18:05:14.582 SC Futures Order Routing/Data | Received security definition for symbol ESZ20_FUT_CME | 2020-09-26 18:05:14.582 SC Futures Order Routing/Data | Received security definition for symbol MESZ20_FUT_CME | 2020-09-26 18:05:14.582 HD Request # 57 | Setting DTC encoding to Binary VLS | 2020-09-26 18:05:14.959 HD Request # 57 | Sending historical data logon request message. | 2020-09-26 18:05:14.959 HD Request # 57 | Requesting Intraday data. Start date-time: 2020-09-25 15:59:59. Record interval: 0. Symbol: NQZ20 | 2020-09-26 18:05:19.729 HD Request # 57 | Decompressing data. | 2020-09-26 18:05:19.811 HD Request # 57 | Receiving Intraday data for NQZ20_FUT_CME starting at 2020-09-25 15:59:59.061000 | 2020-09-26 18:05:19.811 Socket (5) | CloseSocket call. | 2020-09-26 18:05:19.811 Socket (5) | 0 bytes remaining in receive buffer when socket closed. | 2020-09-26 18:05:19.811 Socket (5) | Shutdown started. Waiting for graceful close. | 2020-09-26 18:05:19.811 Historical data download thread signaled to stop. | 2020-09-26 18:05:19.811 HD Request # 57 | Timestamp of first Intraday data file record written: 2020-09-25 15:59:59.910001 | 2020-09-26 18:05:19.812 HD Request # 57 | Received 4 records from 2020-09-25 15:59:59.061 to 2020-09-25 15:59:59.910 (0.8 seconds) and wrote 1 record for NQZ20_FUT_CME | 2020-09-26 18:05:19.812 HD Request # 57 | Completion time: 5s | 2020-09-26 18:05:19.815 HD Request # 57 | Intraday data download complete for NQZ20_FUT_CME. Unique request ID: 58 | 2020-09-26 18:05:19.815 Removing historical data download ID 58. | 2020-09-26 18:05:19.815 Real-time Intraday chart data file updates started for NQZ20_FUT_CME | 2020-09-26 18:05:19.815 Intraday chart data file opened for NQZ20_FUT_CME | 2020-09-26 18:05:19.815 HD Request # 57 | Enabling Intraday chart updating for symbol. | 2020-09-26 18:05:19.815 Triggering next historical data download in queue. | 2020-09-26 18:05:19.815 HD Request # 58 | Downloading Intraday chart data for ESZ20_FUT_CME to the file ESZ20_FUT_CME.scid. Service: cme | 2020-09-26 18:05:19.816 Enabling compression for file: C:\SierraChart\Data\ESZ20_FUT_CME.scid. This may take a while. | 2020-09-26 18:05:19.816 * HD Request # 58 | Download start date-time: 2020-09-25 15:59:59.000 | 2020-09-26 18:05:19.816 HD Request # 58 | Using server: ds21.sierracharts.com port 10150 | 2020-09-26 18:05:19.816 Socket (6) | Creating socket. | 2020-09-26 18:05:19.816 Socket (6) | New receive buffer size: 5242880 | 2020-09-26 18:05:19.816 Socket (6) | Connecting to IP: 216.1.90.129. | 2020-09-26 18:05:19.816 Socket (5) | Socket gracefully closed by remote side. | 2020-09-26 18:05:19.884 Socket (5) | Closed. | 2020-09-26 18:05:19.884 HD Request # 58 | Setting DTC encoding to Binary VLS | 2020-09-26 18:05:19.963 HD Request # 58 | Sending historical data logon request message. | 2020-09-26 18:05:19.963 HD Request # 58 | Requesting Intraday data. Start date-time: 2020-09-25 15:59:59. Record interval: 0. Symbol: ESZ20 | 2020-09-26 18:05:20.032 HD Request # 58 | Decompressing data. | 2020-09-26 18:05:20.100 HD Request # 58 | Receiving Intraday data for ESZ20_FUT_CME starting at 2020-09-25 15:59:59.144000 | 2020-09-26 18:05:20.101 Socket (6) | CloseSocket call. | 2020-09-26 18:05:20.101 Socket (6) | 0 bytes remaining in receive buffer when socket closed. | 2020-09-26 18:05:20.101 Socket (6) | Shutdown started. Waiting for graceful close. | 2020-09-26 18:05:20.101 Historical data download thread signaled to stop. | 2020-09-26 18:05:20.102 HD Request # 58 | Timestamp of first Intraday data file record written: 2020-09-25 15:59:59.973001 | 2020-09-26 18:05:20.102 HD Request # 58 | Received 17 records from 2020-09-25 15:59:59.144 to 2020-09-25 15:59:59.973 (0.8 seconds) and wrote 1 record for ESZ20_FUT_CME | 2020-09-26 18:05:20.102 HD Request # 58 | Completion time: 1s | 2020-09-26 18:05:20.105 HD Request # 58 | Intraday data download complete for ESZ20_FUT_CME. Unique request ID: 59 | 2020-09-26 18:05:20.105 Removing historical data download ID 59. | 2020-09-26 18:05:20.105 Real-time Intraday chart data file updates started for ESZ20_FUT_CME | 2020-09-26 18:05:20.105 Intraday chart data file opened for ESZ20_FUT_CME | 2020-09-26 18:05:20.105 HD Request # 58 | Enabling Intraday chart updating for symbol. | 2020-09-26 18:05:20.105 Triggering next historical data download in queue. | 2020-09-26 18:05:20.105 HD Request # 59 | Downloading Intraday chart data for YMZ20_FUT_CBOT to the file YMZ20_FUT_CBOT.scid. Service: cbot | 2020-09-26 18:05:20.105 Enabling compression for file: C:\SierraChart\Data\YMZ20_FUT_CBOT.scid. This may take a while. | 2020-09-26 18:05:20.105 * HD Request # 59 | Download start date-time: 2020-09-25 15:59:59.000 | 2020-09-26 18:05:20.105 HD Request # 59 | Using server: ds21.sierracharts.com port 10149 | 2020-09-26 18:05:20.105 Socket (5) | Creating socket. | 2020-09-26 18:05:20.105 Socket (5) | New receive buffer size: 5242880 | 2020-09-26 18:05:20.105 Socket (5) | Connecting to IP: 216.1.90.129. | 2020-09-26 18:05:20.105 Socket (6) | Socket gracefully closed by remote side. | 2020-09-26 18:05:20.173 Socket (6) | Closed. | 2020-09-26 18:05:20.173 HD Request # 59 | Setting DTC encoding to Binary VLS | 2020-09-26 18:05:20.252 HD Request # 59 | Sending historical data logon request message. | 2020-09-26 18:05:20.252 HD Request # 59 | Requesting Intraday data. Start date-time: 2020-09-25 15:59:59. Record interval: 0. Symbol: YMZ20 | 2020-09-26 18:05:23.379 HD Request # 59 | Decompressing data. | 2020-09-26 18:05:23.448 HD Request # 59 | Receiving Intraday data for YMZ20_FUT_CBOT starting at 2020-09-25 15:59:59.020000 | 2020-09-26 18:05:23.449 Socket (5) | CloseSocket call. | 2020-09-26 18:05:23.449 Socket (5) | 0 bytes remaining in receive buffer when socket closed. | 2020-09-26 18:05:23.449 Socket (5) | Shutdown started. Waiting for graceful close. | 2020-09-26 18:05:23.449 Historical data download thread signaled to stop. | 2020-09-26 18:05:23.449 HD Request # 59 | Timestamp of first Intraday data file record written: 2020-09-25 15:59:59.020001 | 2020-09-26 18:05:23.449 HD Request # 59 | Received 1 record from 2020-09-25 15:59:59.020 to 2020-09-25 15:59:59.020 (0.0 seconds) and wrote 1 record for YMZ20_FUT_CBOT | 2020-09-26 18:05:23.449 HD Request # 59 | Completion time: 3s | 2020-09-26 18:05:23.453 HD Request # 59 | Intraday data download complete for YMZ20_FUT_CBOT. Unique request ID: 60 | 2020-09-26 18:05:23.453 Removing historical data download ID 60. | 2020-09-26 18:05:23.453 Real-time Intraday chart data file updates started for YMZ20_FUT_CBOT | 2020-09-26 18:05:23.453 Intraday chart data file opened for YMZ20_FUT_CBOT | 2020-09-26 18:05:23.453 HD Request # 59 | Enabling Intraday chart updating for symbol. | 2020-09-26 18:05:23.453 Triggering next historical data download in queue. | 2020-09-26 18:05:23.454 HD Request # 60 | Downloading Intraday chart data for MESZ20_FUT_CME to the file MESZ20_FUT_CME.scid. Service: cme | 2020-09-26 18:05:23.455 Enabling compression for file: C:\SierraChart\Data\MESZ20_FUT_CME.scid. This may take a while. | 2020-09-26 18:05:23.455 * HD Request # 60 | Download start date-time: 2020-09-25 15:59:59.000 | 2020-09-26 18:05:23.455 HD Request # 60 | Using server: ds21.sierracharts.com port 10150 | 2020-09-26 18:05:23.455 Socket (6) | Creating socket. | 2020-09-26 18:05:23.455 Socket (6) | New receive buffer size: 5242880 | 2020-09-26 18:05:23.455 Socket (6) | Connecting to IP: 216.1.90.129. | 2020-09-26 18:05:23.455 Socket (5) | Socket gracefully closed by remote side. | 2020-09-26 18:05:23.516 Socket (5) | Closed. | 2020-09-26 18:05:23.516 HD Request # 60 | Setting DTC encoding to Binary VLS | 2020-09-26 18:05:23.594 HD Request # 60 | Sending historical data logon request message. | 2020-09-26 18:05:23.594 HD Request # 60 | Requesting Intraday data. Start date-time: 2020-09-25 15:59:59. Record interval: 0. Symbol: MESZ20 | 2020-09-26 18:05:23.663 HD Request # 60 | Decompressing data. | 2020-09-26 18:05:23.731 HD Request # 60 | Receiving Intraday data for MESZ20_FUT_CME starting at 2020-09-25 15:59:59.118000 | 2020-09-26 18:05:23.732 Socket (6) | CloseSocket call. | 2020-09-26 18:05:23.733 Socket (6) | 0 bytes remaining in receive buffer when socket closed. | 2020-09-26 18:05:23.733 Socket (6) | Shutdown started. Waiting for graceful close. | 2020-09-26 18:05:23.733 Historical data download thread signaled to stop. | 2020-09-26 18:05:23.734 HD Request # 60 | Timestamp of first Intraday data file record written: 2020-09-25 15:59:59.599004 | 2020-09-26 18:05:23.734 HD Request # 60 | Received 5 records from 2020-09-25 15:59:59.118 to 2020-09-25 15:59:59.599 (0.5 seconds) and wrote 4 records for MESZ20_FUT_CME | 2020-09-26 18:05:23.734 HD Request # 60 | Completion time: 0s | 2020-09-26 18:05:23.740 HD Request # 60 | Intraday data download complete for MESZ20_FUT_CME. Unique request ID: 61 | 2020-09-26 18:05:23.740 Removing historical data download ID 61. | 2020-09-26 18:05:23.740 Real-time Intraday chart data file updates started for MESZ20_FUT_CME | 2020-09-26 18:05:23.740 Intraday chart data file opened for MESZ20_FUT_CME | 2020-09-26 18:05:23.740 HD Request # 60 | Enabling Intraday chart updating for symbol. | 2020-09-26 18:05:23.740 Date Time Of Last Edit: 2020-09-27 11:19:47
|
| Sierra_092620_1051AMCST.png / V - Attached On 2020-09-26 22:49:45 UTC - Size: 101.53 KB - 224 views Sierra_092620_0547PMCST.png / V - Attached On 2020-09-26 22:49:53 UTC - Size: 91.23 KB - 205 views |
| [2020-09-28 23:29:27] |
| ejtrader - Posts: 688 |
|
SC Team - Would you please acknowledge and comment whether you think this is a bug or not? Few of the custom studies are dependent on the T&S and intraday data to be in sync and struggling to maintain them due to this issue. Thank you much for your time.
Date Time Of Last Edit: 2020-09-28 23:30:32
|
| [2020-09-29 19:38:23] |
| |
|
We expect to be going over this, today or tomorrow. There is no need for anything further. It takes too much time for us to go through all of these repetitive details.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2020-09-29 19:38:36
|
| [2020-10-01 16:27:39] |
| ejtrader - Posts: 688 |
|
SC Team - Any update on this please? Thanks |
| [2020-10-02 07:24:06] |
| |
|
Update to prerelease 2176. We did find a small detail which was leading to an additional trade from getting inserted upon the writing of records during a historical Intraday download. But just one trade. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-10-02 11:48:21] |
| ejtrader - Posts: 688 |
|
SC Team - Thank you. I would think the auto triggered historical download events would be handled with the fix you did (would test and confirm). However the manual disconnect/reconnect events are still failing. - Tested in subinstance - the number of records differ in subinstance compared to main instance. - Haven't tested the disconnect/connect behavior on the main instance yet. Good news is - Main instance seems to be behaving much better now. But the subinstance - auto triggered historical download still has issues as well as manual disconnect/connects. Edit - It appears like you have 2 builds for version 2176. 33473 & 33502. I was using the 33473 build which showed the errors. I would try out 33502 build and see if it resolves the issue. Edit 2 - 2176 - Build 33502 - Issue seems to be resolved. If it works consistently for next week - it's all good. Thank you SC team. Thanks Date Time Of Last Edit: 2020-10-04 02:58:37
|
| [2020-10-08 17:53:48] |
| ejtrader - Posts: 688 |
|
SC team - Update on this. So far this seems to be working as expected without any issues. Thank you. On a side note - observed the following: - In the instance where there is only delayed feed(Allow Support for Sierra Chart Data Feeds option is disabled) - the downloaded data differs for the the instruments where I have exchange enabled on main instance vs instruments where I have exchange disabled. For example: - ES(exchange enabled) - when initial download happens - it downloads ALL the data until the very last minute rather than 10 minutes and 10 seconds delay - so intraday file would have more data than what T&S is representing - YM(exchange disabled) - when initial download happens - this behaves correctly - intraday data as well as T&S is delayed by 10 minutes and 10 seconds - This is the correct approach. Wondering if it is possible to bring ES instrument data as well to be delayed similar to YM in this instance? The problem with current approach - the studies which depend on the intraday data & T&S to be in sync won't work in case of ES(as T&S and intraday are Not in sync to begin with but would come in sync after 10 minutes and 10 seconds). This is NOT a problem for YM as both intraday data as well as T&S data are in sync and delayed by 10 minutes and 10 seconds. I have a workaround for this but seems little odd in design for delayed data. All the exchanges should be treated as not subscribed. Thanks |
| [2020-10-08 19:37:22] |
| |
|
- ES(exchange enabled) - when initial download happens - it downloads ALL the data until the very last minute rather than 10 minutes and 10 seconds delay - so intraday file would have more data than what T&S is representing Yes because on the server, it sees that you are authorized for the exchange and provides real-time data. This will not change.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-10-08 20:18:14] |
| ejtrader - Posts: 688 |
|
Thank you. As I have a workaround - this is not a problem. But in general - the flag I have "Allow Support for Sierra Chart Data Feeds" being disabled should have taken precedence over whether I have the exchange enabled or not. The main issue here is - T&S is NOT in sync with the intraday file when intraday data gets downloaded on initial connection. T&S lags 10 minutes & 10 seconds compared to intraday file to begin with and eventually gets caught up. As is the delayed feed is really a wonderful idea and can live with this design - as I have a workaround for this and it is not that critical when T&S lags compared to intraday data. Thanks Date Time Of Last Edit: 2020-10-08 20:23:11
|
To post a message in this thread, you need to log in with your Sierra Chart account: