Support Board
Date/Time: Sat, 28 Dec 2024 08:06:01 +0000
cpu comparison
View Count: 2680
| [2016-04-14 00:37:19] |
| |
|
We will test the chartbook in post #47.
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 |
| [2016-04-14 01:44:42] |
| |
|
Regarding what is said in post #47 and #48 about seeing the CPU usage of one instance go up when working in another instance: cpu comparison | Post: 87479 When historical data is being downloaded in a sub instance from the main instance, the CPU usage will increase because it is serving historical data. But once that is done, merely scrolling a chart back and forth is not going to cause the CPU usage to increase in the main instance if you are not working within the main instance. Also that increase in CPU usage is on a secondary thread. Not the main thread. 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 |
| [2016-04-14 13:51:18] |
| User791263 - Posts: 151 |
|
We know SC is lean and fast. We appreciate your many recent efforts on making it even faster; Seems to help. Like the user said, any lag in orders can wipe us out. An "active" market versus a "fast market" are two very-different animals. Like you, we must design for worst case scenarios. You probably have many reasons why charts are fully-redrawn on every update. It still seems there may be cases where full redraw-back might not be necessary. While fresh on performance work, please give it one last thought. If impossible, you don't have to explain. My scalping system with 43 charts,8 spreadsheets, lots of studies, overlays on a 400ms update, 1 sec block.. lags in a fast market. I set days-back & spreadsheets' records to minimum (under 1000,most). I hid 1/4 of the windows, set many studies to hidden, etc. Windows are small, narrow. I watch 10 to 50 bars, usually. Only LinearRegressionChannel & longer MA's may go back 40-200 bars. I use no drawings except horizontal lines, so long-back drawings don't apply. For users like me, redraw chart to origin seems a waste of resources. You said this can never change. Are you certain, in all cases? What about an option to select redraw bars-back to study maximum? The way you control bars-back in the Volume-by-Price study is ideal. Or, since my windows are narrow, does full-redraw even apply? If not, tell me and disregard remainder. - - - Please consider such an option to not redraw beyond study or drawing requirements max, plus a few bars. An internal check on whether to over-ride such option might be: A partial Hash Sum or remainder Check-digit (modulo) on data from the prior Bar applied to bars beyond study max, compared to "sampling" & hashing the same data at (300ms?) intervals in current bar--- might prove whether redraw from origin is indicated (ie: SC can over-ride setting, as a catch-all for causes only you all know might occur)? |
| [2016-04-14 17:52:14] |
| |
|
If impossible, you don't have to explain.
Yes this is the case. We are not going to go into details.My scalping system with 43 charts,8 spreadsheets, lots of studies, overlays on a 400ms update, 1 sec block.. lags in a fast market. https://www.sierrachart.com/index.php?page=doc/doc_DTCServer.php#UsingDTCServerForDataAndTradingInAnotherSCInstance Or, since my windows are narrow, does full-redraw even apply?
Only what is visible is redrawn.Refer to help topic 30: https://www.sierrachart.com/index.php?l=helpdetails30.html 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 |
| [2016-04-14 19:26:51] |
| |
|
We tested the Chartbook at post #47. The CPU load was 5%. This is with a 500 millisecond Chart Update Interval. We then set the yearly and monthly TPO profile charts to update at five seconds and the CPU usage went to 0% to 1%. We then set the yearly and monthly TPO profile charts to update at a 500 millisecond interval but set them to Horizontal Bars which is perfectly acceptable with those very dense profiles, the CPU usage went to about 3%. If you do not want to take our advice and use a higher Chart Update Interval on those long-term profiles, then that is your choice but there is no point to continue to ask us about this because we have done all we can at this point. There will be some continued performance improvements but not anything of major significance that would make a difference in your case. 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: 2016-04-14 19:36:00
|
| [2016-04-15 00:23:56] |
| i960 - Posts: 360 |
|
Why are we even doing the multi-instance thing in the first place? If it's so additional cores can be used, you only need that type of hack when code isn't thread safe. The correct solution there is: figure out what isn't thread safe and make it thread safe; then "new instance" becomes "new window." |
| [2016-04-15 00:41:28] |
| User20450 - Posts: 330 |
|
is there a way to set chart interval for individual chart , i dont mind having minute data on long term profiles , but no way to switch it for each chart ?
|
| [2016-04-15 01:55:09] |
| |
|
is there a way to set chart interval for individual chart , i dont mind having minute data on long term profiles , but no way to switch it for each chart ?
Yes we have said this more than once. This is documented here: https://www.sierrachart.com/index.php?page=doc/helpdetails30.html#h30.5 If it's so additional cores can be used, you only need that type of hack when code isn't thread safe. The correct solution there is: figure out what isn't thread safe and make it thread safe; then "new instance" becomes "new window." It is for this purpose, and also supports the ability to use the market data and trading functionality from an external service on other systems or virtual machines on the same system. These systems can be in a different location. Threaded programming is much easier said than done. This is massively complicated. It is not even something which we have any contemplation of at this time for the user interface. Unless this is done properly there would not be any benefit to it. And it also has consequences for developers of custom studies because the behavior of those now becomes unexpected. Please do not ask us about this. It is not something which we will consider for the user interface of the program. There is no doubt that programs do get completely screwed up big time by threaded programming which is not done properly. We have seen too much of this garbage around. And additionally, there can only be a single main window with child windows per process with the Windows interfaces that Sierra Chart uses. 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: 2016-04-15 01:56:22
|
To post a message in this thread, you need to log in with your Sierra Chart account: