Home >> Support Board

Support Board

Date/Time: Thu, 19 Sep 2024 22:12:11 +0000

How to Post a Message for Support

Timing problems

View Count: 1946

[2014-04-08 14:18:41] #1 [Go To First Post]
Hendrixon - Posts: 130
I wanted to see if/how "sc.OnExternalDataImmediateStudyCall = true" effects chart update. Setting chart update interval to 2000ms, I expected two outcomes: A. It will plot the chart slow but give true values of studies on every chart update. B. Or it will really refresh the chart when ever there is new trade. I had a study that plotted the local pc millisecond timestamp on a 1 tick chart. In the attached picture, top study is local milliseconds and bottom study is local seconds. For some odd reason the milliseconds just keep going from 0 to 999 in cycles of +/- 150 seconds [two and a half minutes] Setting chart update interval to 1000ms gives the same behavior but with 65-70 second cycles. 500ms also look weird... This means that faster intervals also give wrong timestamps, but since they are fast enough to give more changes we don't know they are wrong. sc.OnExternalDataImmediateStudyCall really works? doesn't seem like it from the plots.


File1.jpg / V - Attached On 2014-04-08 14:18:28 UTC - Size: 17.37 KB - 452 views

[2014-04-08 16:47:56] #2 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
We will test this. However, we do not understand what this means: For some odd reason the milliseconds just keep going from 0 to 999 in cycles of +/- 150 seconds [two and a half minutes] It is hard to make sense of it. 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

[2014-04-08 17:35:50] #3 [Go To First Post]
Hendrixon - Posts: 130
Just look on the picture. On a 1 Tick chart like this, the milliseconds (top study) should be all over that place, very random... but they don't... they just orderly go from 0 to 999. on a 2000ms chart update interval (like in the picture) it takes two and a half minutes for the milliseconds to go from 0 to 999. See the bottom study showing seconds... going from 0 to 59 normally... and see how you can almost fit 3 MINUTES in how long it takes the "milliseconds" to do their thing there... Sorry I can't explain this better cause I can't make any sense why SC behaves like that. its too weird. For local seconds time stamp use this: int& IndexFollow = sc.PersistVars->i1; if (IndexFollow < sc.Index) { SYSTEMTIME systime; GetLocalTime(&systime); IndexFollow = sc.Index; Second[IndexFollow] = systime.wSecond; } For milliseconds use this: int& IndexFollow = sc.PersistVars->i1; if (IndexFollow < sc.Index) { SYSTEMTIME systime; GetLocalTime(&systime); IndexFollow = sc.Index; Millisecond[IndexFollow] = systime.wMilliseconds; } Remarks: 1. Don't use sc.CurrentSystemDateTime cause its wrong, it rounds "seconds" instead of truncating so I don't trust it on anything. For example you report ticks timestamp like this: 00:00:05.450 is rounded to 00:00:05 (five) 00:00:05.550 is rounded to 00:00:06 (yes SIX) Those are real milliseconds from the feed... not your counter. 2. use sc.OnExternalDataImmediateStudyCall = true; 3. you need to make sure your local time is spot on cause even with Meinberg's NTP client you could get +/-150ms from real time based on your system quartz frequency drift. Date Time Of Last Edit: 2014-04-08 17:37:49

[2014-04-11 13:06:18] #4 [Go To First Post]
Hendrixon - Posts: 130
I used the latest 1119 SC version to make the attached picture. Charts are the same 1 Tick bars of CLK4. Chart on the left is set to 1000ms chart update interval and chart on the right is set to 10ms update interval. Bottom green plot is local time "Seconds" part... as can be seen they are not totally identical. Top white plot is local time "milliseconds" part... and here its totally different plots. You can see the milliseconds on the left (1000ms) chart keeps building from 0 value to 999, almost in sync with the "seconds". Also see how this buildup takes almost a full minute to complete. And this is when sc.OnExternalDataImmediateStudyCall = true which should force SC to calculate studies on every new trade data.


File1.jpg / V - Attached On 2014-04-11 13:03:28 UTC - Size: 82.7 KB - 396 views

[2014-04-22 13:04:29] #5 [Go To First Post]
Hendrixon - Posts: 130
Any update on this? Comparing to a different platform that by default calculates on every tick, I'm 99% sure that "sc.OnExternalDataImmediateStudyCall = true" simply doesn't work.

[2014-04-22 14:58:56] #6 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
We will be looking into this, but the results that you see when you set the milliseconds depends upon the function you are calling which is a Windows function. Sierra Chart would not affect that. What you put into a study sc.Subgraph array is not going to change. We will be doing testing of this, this week most likely. Our test will not be using your own code, we will be using a different method to determine the time. 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

[2014-05-15 11:42:39] #7 [Go To First Post]
Hendrixon - Posts: 130
Any update? Different timings with different methods is one thing (and understood it could take time to check), but the main issue is "sc.OnExternalDataImmediateStudyCall = true". It simply doesn't work. Can you please look into it? Thanks

[2014-05-16 05:22:23] #8 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Something always gets in the way of this. But we are going to start the work to set up the test for this in the morning. 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

[2014-06-02 10:05:06] #9 [Go To First Post]
Hendrixon - Posts: 130
Just checking in.

[2014-06-03 06:41:04] #10 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Something always gets in our way of this. We will try for this week. 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

[2014-06-17 04:06:40] #11 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
We now finally had some time to work on this. sc.OnExternalDataImmediateStudyCall was not working. When you set it to TRUE, it would do nothing different. There was an incorrect check in the code preventing it from working. In regards to what you see with milliseconds, that is outside the scope of our testing. We cannot debug your own code. This is the test function you should use for this variable: SCSFExport scsf_ImmediateCallExample(SCStudyInterfaceRef sc) { if (sc.SetDefaults) { // Set the configuration and defaults sc.GraphName = "Immediate Call Example"; sc.AutoLoop = 1; //Increases CPU load. Not recommended. Use only for special purposes. sc.OnExternalDataImmediateStudyCall= true; sc.FreeDLL = 0; return; } if(sc.Index == sc.ArraySize - 1) { // Log the current time SCString DateTimeString = sc.DateTimeToString(sc.CurrentSystemDateTime,FLAG_DT_COMPLETE_DATETIME_MS); sc.AddMessageToLog(DateTimeString, 0); } } This code will only work in the next release which solves the problem. 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

[2014-06-20 13:00:20] #12 [Go To First Post]
Hendrixon - Posts: 130
Just as I said, sc.OnExternalDataImmediateStudyCall didn't work. Will test it next week once I'll upgrade. Thanks. Regarding the timing issue, it has nothing to do with my code. Absolutely nothing. Its all in your sc.CurrentSystemDateTime member. its really not rocket science, I'll explain it again: If a trade (i.e. Tick) has a local system time of 10:10:10.449 and you pole sc.CurrentSystemDateTime for just the "Seconds" part, it will give "10". But if the Tick has a local system time of 10:10:10.501 and above, than poling sc.CurrentSystemDateTime for just the "Seconds" part, will respond with "11". You or microsoft or whoever, is responsible for rounding the milliseconds instead of truncating them. You must find out why it happens, since local time is half the problem. I found it here since I can see the time stamp down to milliseconds (its my local system time). But, if you round the milliseconds on the "datafeed" timestamp (instead of truncating it), we the traders can't even know it happens... since we still don't have proper datafeed millisecond support. Nothing to do with my code:-)

[2014-06-20 17:37:57] #13 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
In the next release sc.CurrentSystemDateTime will be changed not to include milliseconds. Since it includes milliseconds, when you do get the second, it will be rounded to the nearest second. This is how it works. This is also not the data feed timestamp. It is the current system date time. In the next release this will be added: sc.CurrentSystemDateTimeMS. This will include milliseconds. 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: 2014-06-20 17:39:25

[2014-06-22 21:33:13] #14 [Go To First Post]
ganz - Posts: 1048
SC Support In the next release this will be added: sc.CurrentSystemDateTimeMS. This will include milliseconds. v1149 Looks like it is not released yet? ... also ... I'm trying to store a tick's datetime = 41813.000 it displays as 2014-06-23 00:00:00.500 say 1 ms = 1 day / 86400 000 = 0,000000012 if datetime = 41813.000000012 then it displays as 2014-06-23 00:00:00.501 if datetime = 41813.000000024 then it displays as 2014-06-23 00:00:00.502 so the question is: why 500 ms is already there or it's because of me? thnx

[2014-06-22 21:45:52] #15 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
If you are seeing milliseconds of 500, then the value could not be 41813.000 exactly. It must be some slightly higher value. 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

[2014-06-23 11:24:25] #16 [Go To First Post]
Hendrixon - Posts: 130
SC, Can you please comment/verify if you truncate or round the datafeed's timestamp milliseconds to report "sc.LatestDateTimeForLastBar"? Thanks

[2014-06-23 19:50:12] #17 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Refer to the documentation for sc.LatestDateTimeForLastBar. The data feed milliseconds are never used. 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

[2014-06-24 13:11:10] #18 [Go To First Post]
Hendrixon - Posts: 130
Its not what I asked but never mind, there are more important things. Installed ver 1150 and here are my findings: 1. "sc.CurrentSystemDateTimeMS.GetSecond()" still rounds to the next second if milliseconds are above 500 2. sc.OnExternalDataImmediateStudyCall has issues. I set Chart Update Interval to 1000ms to see if it works. 2a. Using "sc.OnExternalDataImmediateStudyCall = true" the chart stutter/stuck every few seconds. You see that by moving the mouse cross hair around, it gets stuck and released after 1-2 seconds. happens every 10-15 seconds maybe? 2b. To see if the data lags, opened a second chart copy without a study and found that the "sc.OnExternalDataImmediateStudyCall = true" chart data always lags. *Keep in mind I checked things on a live crude oil chart (1 Tick) before pit open, we're talking 10-15 trades per minute. no computing load*** 2c. Out of curiosity I set Chart Update Interval (general settings) to 10ms. * The "sc.OnExternalDataImmediateStudyCall = true" chart stopped lagging. both charts tracked pretty much the same. * Mouse cross hair gets stuck much less often and for a very short time. Conclusion "sc.OnExternalDataImmediateStudyCall" still influenced by the chart update interval. Has nothing to do with load (10-15 ticks per minute is nothing)

[2014-07-19 23:42:13] #19 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
1. "sc.CurrentSystemDateTimeMS.GetSecond()" still rounds to the next second if milliseconds are above 500 This should be expected. 2. We will have to test later on, your other findings with sc.OnExternalDataImmediateStudyCall. Last time we tested this, it does work properly. We would expect occasional freezing of the user interface when the market is active when using this. 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: 2014-07-19 23:42:32

[2014-08-26 10:25:15] #20 [Go To First Post]
Hendrixon - Posts: 130
Guys, Since more than 4 months have passed, and its obvious (for what ever reasons) this is going to take many more months to sort out, please allow in the next release a 1 millisecond refresh rate. It's better than nothing and it can be done now. Thanks

To post a message in this thread, you need to log in with your Sierra Chart account: