Support Board
Date/Time: Mon, 25 Nov 2024 01:30:25 +0000
Significant Lag past version 1958
View Count: 3110
| [2019-07-31 09:12:18] |
| User657944 - Posts: 173 |
|
Well I really like to understand two points: 1) As per you istruction manual:The Chart Update Interval sets how often the chart graphics are updated and studies are calculated when connected to the Data/Trade server. When market data, Trade Order data or Trade Position data is received, it will be displayed within this time interval. So if I set the interval to 100 or 200 ms or to 800/1000ms how is it possible that this is not slowing the calculation of the studies (let me say 4-5 studies that must be calculated to get a trade signal on a 1 sec chart)? 2)In another post you answered me that the Milliseconds timestamp and the Interval update are two different things can you please explain how they are different and why they should not influence each others? There's no any critics vs You it is just to understand, since as a trader I'm pragmatic if I have a software version that, at least from a visual point of view it is faster than another I will stay with the faster one. thx Alberto |
| [2019-07-31 09:12:32] |
| |
|
If you have 20 charts and each chart between the graphics and the calculations takes about 100 ms to calculate and draw , then this would mean that in order to have a responsive user interface you would need to use a Chart Update Interval of 2000. However most of the load is from graphics and if not all of the charts are visible, at the same time, then the load of those nonvisible charts is going to be below 100 ms. So therefore the maximum needed interval would be 2000 in this particular scenario. In other words you would not need to use an interval that low necessarily. 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: 2019-07-31 09:21:44
|
| [2019-07-31 09:19:36] |
| User657944 - Posts: 173 |
|
Ok got it but I have a scenario that is the same for 1941 and 1963 with the first one at 100 ms interval everything works fine I did not get any delay in data or buttons responsive time the question is why? CPU, PC, OS are the same the difference is the 1941 is on a Transact bridge while the 1963 on a websocket connection and it has new features like the bid/ask counting that is more precise etc. And last but note least it is not only the graphics The Chart Update Interval sets how often the chart graphics are updated and studies are calculated and this is important to get a prompt output to get the trade, Date Time Of Last Edit: 2019-07-31 09:21:55
|
| [2019-07-31 09:23:09] |
| |
|
Based on the fact that you are noticing a problem with 1963 with "apparent poor performance", shows that you are definitely not getting 100 ms updates at all regardless of the setting. The updates are actually slower. To improve performance of trading, refer to: Overview of Trading: Sierra Chart Configuration for Most Low Response Time Trading 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: 2019-07-31 09:23:59
|
| [2019-07-31 09:27:22] |
| |
|
Here is another piece of information. Previously we were using the operating system timer functionality to drive charts but that is a low priority message. This is from the Microsoft documentation: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
Now the charts are driven with a normal priority message that when received, is followed through on. Sierra Chart does not ignore these messages whereas with OS timer messages they are low priority and when there was more than one of them in the queue for a particular chart, they were all discarded and only one of them followed. 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 |
| [2019-07-31 09:48:05] |
| User657944 - Posts: 173 |
|
look at my post hide post lag 1958 thx
|
| [2019-07-31 10:04:18] |
| |
|
There is no reason to keep a post hidden. When we take the time to answer users with a lot of detail we want the information public. The post is here: lag on 1958 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 |
| [2019-07-31 11:13:49] |
| TedMar - Posts: 190 |
|
sc1963 , i use 6 symbols in a chartbook with 10 Charts , now changed from 10ms to 100ms Chart Interval, perfomance is little better, but in compare to v1958 still very poor my ping to Broker/Datafeed is 8ms , if i use AutoTrading study, Study react after 100 ms when Chart is updated? i understand post #7, but maybe is posible add checkBox for optional dropping frames in old style like v1958? Date Time Of Last Edit: 2019-07-31 11:52:34
|
| [2019-07-31 12:15:40] |
| User34124 - Posts: 276 |
|
I second the choice to use the old style like 1958. Spent hours loading chartbooks and reverting to and from the versions, but anything >1958 WITH 2000ms Chart Interval does NOT work (as soon as I go over about 30 charts it crashes/waits until I force close via task manager). Granted I have a lot of charts per chartbook I need to use, these work fine with small lag on 1958. I can't go over 2000ms as that would render a very ugly user experience.
|
| [2019-07-31 12:48:54] |
| User972768 - Posts: 166 |
|
I have tried v1962 with default setting of 500ms in Global Settings. All of my charts are set to 0 update interval (in other words to use Global setting). My chart book has 22 charts and present data about 8 symbols. What I noticed is that GUI is mostly unusable - I experience delays of few seconds between click on the tab to change chart and actual change. What I also noticed is that around 8am US Eastern my system is almost 80% busy doing disk IO and reading 30-40 Megabytes per second. There is very little updates to ES around this time of the day and it is not like I just opened Chartbook and it loads tons of data. At the moment all of my charts are showing current data without progress bar. Flipping back to v1957 shows 0% disk IO under same conditions and system is completely responsive. From CPU point of view: v1962 Sierra consumes about 80% and 50% under v1957. Is there anything I can do to lower Disk IO in my case under v1962? Thanks and best regards Date Time Of Last Edit: 2019-07-31 15:57:04
|
| [2019-07-31 13:48:12] |
| User657944 - Posts: 173 |
|
to post 98 this is exactly what happens to me and I explained here in the post to SierraEng but the solution they suggest is to set bigger update interval from 500ms and more as per number of charts that we have, I will make some test in the weekend but if so much people have this issue after 1957 or 1958 there's something impacting MSFT OS that was not doing that in the previous release.
|
| [2019-07-31 13:57:33] |
| caligola - Posts: 116 |
|
It is clear that users are not setting that properly and maybe we should just remove that setting altogether.
Please don't remove this setting. It's very useful to slow down chart that doesn't need fast update and save CPU power to be used in more critical charts Maybe you could be more clear that it should be used to SLOW DOWN charts and not the opposite as users are trying to do not understanding what they do |
| [2019-07-31 14:18:08] |
| TedMar - Posts: 190 |
|
Please don't remove this setting. It's very useful to slow down chart that doesn't need fast update and save CPU power to be used in more critical charts
Maybe you could be more clear that it should be used to SLOW DOWN charts and not the opposite as users are trying to do not understanding what they do i wrote allready in post #32, best way is crate a option checkBox for enable/disable dropping update frames global. +1 Date Time Of Last Edit: 2019-07-31 14:20:48
|
| [2019-07-31 17:05:54] |
| |
|
We understand the key problem here. We have to ensure that timer events are placed behind user interface events. We will do that.
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 |
| [2019-07-31 18:12:45] |
| User972768 - Posts: 166 |
|
Thank you @Sierra Chart Engineering But that doesn't explain extra busy disk I/O mentioned in Post #34. Any thoughts about that? Thanks |
| [2019-07-31 18:15:23] |
| |
|
Some of the things we see posted in this thread are just simply plain utterly ridiculous and are not from Sierra Chart at all: This is one of them: What I also noticed is that around 8am US Eastern my system is almost 80% busy doing disk IO and reading 30-40 Megabytes per second.
If Sierra Chart is not loading intraday chart data, Then this is not from Sierra Chart. No chance in hell this is from Sierra Chart. And we mean no chance in hell. You need to find out what is going on in your system that is causing this. This is not Sierra Chart!!! We mean there is no chance in hell this is from Sierra Chart. Once you figure it out, do not post here. This is going to be some kind of system issue specific to your system. 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: 2019-07-31 18:24:51
|
| [2019-07-31 18:19:34] |
| |
|
And those users who are using 10 ms update you are creating your own problem. Do not even post here if you are using this low of an update interval. That is ridiculously low. And we mean that is ridiculously low!! You are going to cause a problem. And we document that. You are just completely wasting our time by posting here about a problem when you are using a ridiculously low update interval. 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: 2019-07-31 18:19:47
|
| [2019-07-31 19:01:04] |
| User972768 - Posts: 166 |
|
@Sierra Chart Engineering With all due respect I think you guys crossing the line here. Basically, you call every user an idiot. You do not create this piece of software for your own sake. We pay for right to use and this combined supports your families. I truly believe that you should be more respectful to your customers and not degenerate discussions and issue reporting to plain Hollywood movies where swearing is a norm. I will wait until end of cash session today and attempt to recreate same conditions as I experienced this morning. Please keep discussions at professional level. Not everyone of your customers is an expert in software coding. I've worked with many software companies through many years and can say that this is my 1st place where provider allows itself to go to such extents. Bug reporting is vital part of SDLC and in the end it is not to make developers unhappy, but to make piece of software better. There is no single developer in the world who create perfect (bug-less) code from 1st attempt. And more complex software becomes, more complex issues it exposes. So let's work together to make Sierra Chart better Date Time Of Last Edit: 2019-07-31 19:18:05
|
| [2019-07-31 19:27:49] |
| |
|
can say that this is my 1st place where provider allows itself to go to such extents. This is taken as a compliment.
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 |
| [2019-07-31 19:34:31] |
| User657944 - Posts: 173 |
|
The below post that it is posted and locked it's an example of a fair and reasonable answer to customers in the spirit of collaboration: THANK YOU SO MUCH Sierra Eng. Managing Performance with Version 1959 and Higher and the Chart Update Interval In regards to the handling of timer events to update charts, we do acknowledge, that there is an issue for some users with the user interface not being responsive when there are a lot of charts open and those charts have complexity with their display and/or with the studies, which we have not been able to resolve as of so far. We understand the underlying reason for this. It has to do with the fact that timer events must have a lower priority than user interface events during processing. We will look at how to resolve that. For the time being we will go back to the old method of updating charts. We are going to be releasing 1964 in about 20 minutes. Also for the record in our testing we are not observing any issue with the user interface being nonresponsive with the new method of updating even when using a short update interval like 100 ms and 18 charts. But we do acknowledge that with large complex layouts, that there very well can be a problem if user interface messages are not given priority. Date Time Of Last Edit: 2019-07-31 19:35:54
|
| [2019-07-31 21:16:15] |
| |
|
When we released version 1963 and continue to hear reports of the user interface still not being responsive at times, we were surprised that this was the case. Giving priority to user interface messages like keyboard events and mouse pointer events, would we think would solve the problem but the implementation of that may not really be very efficient or practical, or may not even be possible at all especially with the current Microsoft framework that Sierra Chart is using. With the changes being made, to remove MFC from the program it will be possible later if it is not now. Thinking through this more, we now realize where the dynamic management of the chart update interval that 1963 has, was not fully implemented in the best way. Basically what happens is that when a timer event is triggered, as soon as the chart completes its update, we then record the completion time. If the difference between the original trigger time and the completion time exceeds the Chart Update Interval, then that is the delay for the next update and not the original chart update interval. So if the update interval is 10 ms, and the completion time after trigger was 1000 ms later, the next trigger will be 1000 ms later. And then what happens is that delay of 1000 ms is gradually stepped down with each subsequent update towards the original Chart Update Interval. The problem is the reason for this 1000 ms delay is from other charts being updated as well at the same time so still there is an extremely minimal opportunity for user interface messages to get processed with chart updates occurring one right after the other. What we are going to do now is add an additional 500 ms for the next update. This may be too much of a delay, but we want to start with that to see if it resolves the problem. We are going to release later today 1965 with the new timer management, and this additional inserted delay. And also, in regards to our comments about removing the Chart Update Interval, this is not going to happen but we do realize that it does have to be managed automatically to some extent. 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: 2019-07-31 21:33:08
|
| [2019-07-31 21:29:47] |
| User972768 - Posts: 166 |
|
I have tried multiple times to reproduce the disk IO issue under 1962 and 1964 with no success. Easiest explanation is that I had one of the charts still loading data when I observed the issue this morning. I'm fine to leave my report as "not an issue". I also would like to report that in my environment v1964 has much more responsive User Interface comparing to v1962. Best regards |
| [2019-07-31 21:32:47] |
| |
|
1964 uses the operating system timers with full clearing out of the timer events from the queue at each update. 1965 will have the new method with the additional 500 ms delay. Now that delay is not going to be a hardcoded delay. We will make it user adjustable. It may just become the Chart Update Interval itself.
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: 2019-07-31 21:33:29
|
| [2019-08-01 14:14:55] |
| User379468 - Posts: 508 |
|
Is there a way to display in the platform or each chart any delay/overlap occurring or what the dynamic interval adjustment is doing so users can fine tune the correct update interval for their needs?
|
| [2019-08-01 14:40:49] |
| User972768 - Posts: 166 |
|
User379468 I believe that easiest way to get that information at the moment is Chart Settings >> Advanced Settings 3 >> Chart drawing time (at the bottom) In light of this discussion it would be nice to have some sort of floating window that will show list of all charts and their refresh time all at once. Perhaps some extra symbol showing enforced extra delay would be nice too. Other option to show this information could be CW menu, right beside window title Date Time Of Last Edit: 2019-08-01 14:49:05
|
| [2019-08-01 15:00:34] |
| User379468 - Posts: 508 |
|
Got a SC UI freeze in 1966, only 3 charts open, global update set to 900ms, 2 charts set to 100ms, SC CPU use around 7%. Charts continued updating fine, but no control bar or main window or file menu access or response, required task manager process kill.
|
To post a message in this thread, you need to log in with your Sierra Chart account: