Support Board
Date/Time: Sat, 28 Dec 2024 08:10:45 +0000
cpu comparison
View Count: 2681
| [2016-04-03 12:31:27] |
| User20450 - Posts: 330 |
|
i made 10 charts of same time on SC , NT and TOS , same indicators ( iknow some process diff ) , and here is what i have , so def something loading up , and its not a huge deal but it lags my cursors and bars incoming so to place an order lags , is issue and we have a big group that uses all similar charts and load varies but with new orderflow and volume bid/ask stuff (all stock not 3rd party) , we are all getting some lag from CPU at times splitting the load on new instance is nice but seems some of the new instance load is carried over to fist one still , ver 92 thanks |
 2016-04-03_08-21.jpg / V - Attached On 2016-04-03 12:25:22 UTC - Size: 21.96 KB - 413 views |
| [2016-04-03 17:38:33] |
| ganz - Posts: 1048 |
|
User20450 ToS is the Java app NT is the .Net app SC is the 32 bit native app so it might be because of 32 -> 64 bit transitions or something like this (in case there are no issues with SC) |
| [2016-04-03 21:23:14] |
| |
|
Your experience is completely opposite of our other users. We cannot offer any further help and we will spend no further time on this. We do not know exactly what you are doing and what the issue with your system is. Furthermore, the market is not even open and posting the screenshot tells us absolutely nothing. We have no idea what you are doing with Sierra Chart. Refer to help topic 30: https://www.sierrachart.com/index.php?l=helpdetails30.html If Sierra Chart does not meet your requirements, then use another program. It is fine with us. Sierra Chart is very fast and efficient. And there is some other reason for the problem 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-03 21:25:20
|
| [2016-04-03 21:27:28] |
| |
|
One other thing, if you decide to continue to use Sierra Chart, and being you are using File >> New Instance, update to the current version of Sierra Chart because it is new feature and additional improvements have been made to 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 Date Time Of Last Edit: 2016-04-03 21:30:51
|
| [2016-04-03 23:28:39] |
| User20450 - Posts: 330 |
|
Can't believe u would say that others have opposite , when there are new cpu issues listed in forum daily I'm not complaining , I'm trying to provide feedback to help issues , I pay for the platform and have a right to talk about issues , That picture was taken Friday at 330 pm estate, so yes markets where open |
| [2016-04-03 23:31:42] |
| User20450 - Posts: 330 |
|
And I love sierra and will continue to use and promote it for others to use as I have always done , thanks
|
| [2016-04-03 23:35:08] |
| |
|
That may be the perception, but it definitively is not representative of the vast majority of our users. Can't believe u would say that others have opposite , when there are new cpu issues listed in forum daily
When users do not have a problem they are not going to post here. You are only seeing the postings from those people that have an issue, and there is nothing we can do about that. It has to do with user systems, and what they are doing with Sierra Chart. Sierra Chart is extremely fast with data processing. And one particular issue that was recently posted, was definitively incorrect and completely misleading. That we are 100% certain of. The only two known things in Sierra Chart which are CPU heavy, and we recognize as a potential problem are certain uses with New Spreadsheets and replay back testing. Any time we become aware of a performance issue in New Spreadsheets we work to resolve 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 Date Time Of Last Edit: 2016-04-03 23:39:48
|
| [2016-04-03 23:41:13] |
| |
|
The point is, we have done all we can: I'm not complaining , I'm trying to provide feedback to help issues , I pay for the platform and have a right to talk about issues , 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-03 23:52:49] |
| |
|
To say that Sierra Chart is a CPU heavy and sluggish program is very very contrary to the vast majority of use cases of Sierra Chart. It is known for its very fast speed and reliability. Another thing to be aware of is when Sierra Chart is running during real-time updating, most of the CPU load comes from graphics output. So if the graphics performance on your system is not good or you are using a low Chart Update Interval which would be under 200 milliseconds, then you can have a problem with 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 Date Time Of Last Edit: 2016-04-03 23:53:39
|
| [2016-04-04 00:31:23] |
| User20450 - Posts: 330 |
|
i agree and i never said those words , i said it was causing a load some where , and most people dont use data heavy charts , orderflow and bidsask profiles , , if i run macd and stocastic its extremely fast sure but for how i trade , i need data processed fast on small time frame charts , and the more and more retailers that get into this newer trading info , you will see the requirements increase , thats all
|
| [2016-04-04 01:01:07] |
| |
|
Those are our words. We are just simply generalizing the issue you have expressed many times. This should still not be a problem: data heavy charts , orderflow and bidsask profiles ,
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-04 01:35:08] |
| User20450 - Posts: 330 |
|
i know u say it shouldn't be but it is , i wouldnt waste ur time if it was just me , but like i have said before we have a decent size group that all use sierra and experience similar issues when running these studies . even 1 chart with weekly profile on it , loads up big time , i shouldnt have to use 10 ticks per volume bar to get it to run smooth , here is 1 chart on new chart book nothing else open , 90 days of data on a weekly profile and its running 14% of my cpu , just makes no sense to me , if its something on my end that will be great , but would need to trouble shoot with u guys , is there anything wrong with settings ? |
Attachment Deleted. 2016-04-03_21-31.jpg / V - Attached On 2016-04-04 01:31:52 UTC - Size: 238.56 KB - 411 views 2016-04-03_21-32.jpg / V - Attached On 2016-04-04 01:32:54 UTC - Size: 156.47 KB - 401 views |
| [2016-04-04 01:42:27] |
| |
|
Those kinds of charts with a tick size of .01 and a block size equivalent to the tick size is going to be very graphics intensive especially on the CL market. There is simply no way around that and we have no practical solution if you do not want to increase the ticks per block. Also, this is a documented item in help topic 30. 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-04 01:43:48
|
| [2016-04-04 01:45:59] |
| |
|
even 1 chart with weekly profile on it , loads up big time , Why do you say that: i shouldnt have to use 10 ticks per volume bar to get it to run smooth , You should not even notice visually hardly any difference because there are so many prices across a very small area anyway. 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-04 01:47:16
|
| [2016-04-04 01:46:51] |
| User20450 - Posts: 330 |
|
lol so that is an issue , why would u not want to resolve this ? i can do this in crappy ass ninja with same data , so i would hope sierra can do it no prob thanks |
| [2016-04-04 02:20:13] |
| |
|
If you do not want to increase the Letter/Block Price Increment, then the only way to resolve this is to reduce the amount of blocks actually drawn on the chart. Not really sure how we would do this. We also have to look at the code to see how all of this is done to see if there any performance improvements that can be made but probably that would be minimal if anything. 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-04 11:34:17] |
| User20450 - Posts: 330 |
|
ok thank you
|
| [2016-04-04 21:11:24] |
| i960 - Posts: 360 |
|
I increased my ticks per volume on these types of profile charts ages ago due to SC using excessive CPU to redraw them. It gets even better though. If you keep up a long-term market profile chart (say like 6 months) it'll just grind CPU on every single tick received. SC folks, there's no need to get so defensive here. You're obviously doing something suboptimal/naive for every piece of data being input into the profile drawing engine. We're not exactly dealing with 3d rendering here, these are simple 2d graphic representations, and my gut feeling is you're redrawing things based on all input received (hence O(n) or possibly O(n^2) factor problem) rather than doing it additively/incrementally. |
| [2016-04-04 21:33:05] |
| |
|
Any time the chart is updated for example when a new trade is received and the Chart Update Interval has elapsed, the entire chart window is redrawn. This cannot change and will never change. The basic problem is there is a lot of drawing to be done to draw all of the TPO blocks when there are a wide range of ticks in the chart and when the block size is a single tick. One optimization is that a row of blocks could be drawn as a horizontal line and that is the only thing we have come up with so far to improve this. Also this is not true: it'll just grind CPU on every single tick received.
Charts are never updated on every single tick. This is not even technically possible.
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-04 21:35:14
|
| [2016-04-04 21:42:40] |
| i960 - Posts: 360 |
|
You said this, which agrees with what I said: Any time the chart is updated for example when a new trade is received
and then you said this, which goes against which you just said: Charts are never updated on every single tick. This is not even technically possible.
A trade can be a tick, so I'm not sure how ticks magically fall outside the realm of a chart being updated. Surely your graphics rendering code has a concept of partial updating, doesn't it? On top of that, if you put some thought into it, you'll realize that not every single tick has to be reanalyzed/redrawn for a data structure that is inherently additive in nature. This isn't exactly a graphically intensive thing being done here - but the CPU usage is significant for every single input trade. Date Time Of Last Edit: 2016-04-04 21:45:39
|
| [2016-04-05 01:14:24] |
| |
|
Letting you know we are working on TPO Profile Chart performance improvements now. At the very least CPU usage will drop 50 percent. And another drawing mode we are working on should eliminate about 90 percent of the CPU usage. Previously when the user mentioned a performance issue, we asked for a screen image of the TPO Profile chart. We never got it and did not spend any further time on it because we had nothing to work with. And then just in the last week or two, they said they increased Letter/Block Price Increment but according to them it made almost no difference, so we thought there was not a problem to look into either related to that. Now when we saw the TPO Profile charts given in this thread, we can clearly see what they are doing and we have an understanding of the problem. So we are working on optimization to dramatically improve performance to accomplish what they need in a more optimal way. So the issue is we did not have sufficient information until now. And also needed a little time to determine a good solution. 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-05 03:46:06] |
| User20450 - Posts: 330 |
|
Thank you ,
|
| [2016-04-05 05:01:31] |
| |
|
We are releasing version 1393 now. You will notice an immediate reduction in CPU usage with the TPO Profile Chart study. The way scaling is handled is different and more efficient. The automatic adjustment of the scale based upon the high to low range is not yet fully implemented but the basic functionality works. You will also see a new input named "Sub Period Price Display Style". It can be : Blocks Letters Horizontal Bars (This one is somewhat limited with display functionality but it is extremely fast). Based on the screenshots you show above you should be able to accomplish what you need with 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: 2016-04-05 05:02:07
|
| [2016-04-09 22:31:25] |
| |
|
Regarding the issue described in post #12 and our response in post #13, we decided to do our own test. Using CL futures, a TPO block size of .01, TPO blocks drawing style, and many TPO profiles on the chart, we ran a high-speed replay at 960 times and the CPU usage was about consistently 2%. During a replay there is a dramatically much faster rate of updating of the chart window than real-time updating. Therefore, we saw absolutely nowhere near the CPU usage you are showing in post #1. We then updated to 1393 and the CPU usage went to zero percent with the same high-speed replay. Therefore, apparently your system does not have good graphics performance. The system uses an Intel HD Graphics 4600 graphics adapter and the corresponding Intel driver. 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-09 22:35:23
|
| [2016-04-09 23:54:27] |
| i960 - Posts: 360 |
|
GPU performance doesn't even matter here. It's a 2D graphics render, the GPU is barely even being used. The people who have run with low TPO block sizes absolutely have seen this, so you need to take into account that it's not a user issue, not a system issue, and quite POSSIBLY a code issue. many TPO profiles on the chart
Define "many", and you probably want to define the duration of your chart as well (maximum days loaded). |
To post a message in this thread, you need to log in with your Sierra Chart account: