Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sat, 18 May 2024 04:54:55 +0000
[Locked] - CPU usage for multi-core processor
View Count: 15057
| [2014-04-11 08:38:35] |
| Futures Operator - Posts: 239 |
|
Regarding the original OP's post, since he experienced lag even with low CPU usage, is it correct that CPU usage is not a reliable indicator for performance requirements in Sierra? And even with low CPU usage, one would benefit in preventing lag with a faster CPU than even an i5? Josh, curious which i5 do you have?
Date Time Of Last Edit: 2014-04-11 23:18:13
|
| [2014-04-11 23:15:23] |
| vegasfoster - Posts: 444 |
|
Someone correct me if the following is wrong, but my understanding is that I7s, I5s, and I3s are all manufactured as the same chip, just due variances in the manufacturing process some chips will come out with faster processing speeds than others and some chips will also have defective cores. So the slower chips are locked at slower speeds and faster chips are locked at a higher speed and sold for more money. Some of the chips can go even faster than the highest marketed speed and are sold at a higher price as unlocked chips, where the speed can be manually increased by the user, called overclocking. I7s have 4 cores with hyperthreading enabled (hyperthreading means each core has 2 virtual cores, so an I7 will have 4 actual cores and 8 virtual cores), I5s have 4 cores with hyperthreading intentionally disabled, and I3s have both hyperthreading disabled and 2 of the 4 cores intentionally disabled, either or both of which may have also been defective. So, the benefits of I7 over I5 are 1) the I7 has hyperthreading enabled, 2) the I7 has an insigicantly (IMO :)) higher base clock speed on the top of the line unit, and 3) an unlocked I7 can typically overclock slightly faster than an unlocked I5. So, for Sierra Chart, if you are not running more than 4 instances of SC at the same time, or doing many other things at the same time, or max overclocking, then you likely won't benefit from an I7. |
| [2014-04-23 19:44:03] |
| SgtJ - Posts: 154 |
|
Vegas, I'd say most of that is spot on. I went with the i7 because it left me more headroom for the future for just a little more $. I'm thinking about building another and I'd still choose the i7 (4770) fwiw.
|
| [2016-01-27 06:39:45] |
| User791263 - Posts: 151 |
|
It has been near 2 years since Trading PC/CPU cores utilization was visited. It's time to revisit it. The goal is providing S.C. users a competitive advantage in speed in fast markets with heavy charts, spreadsheets, tick and 1-second charts, etc. I come from TradeStation 2000i with its modular Data Server (Global Server-a separate symbols-manager, feed handler and file writer). A background partial (core) or full instance of S.C. could work as an optional setting (instead of always requiring full multiple S.C. instances installation). The goal is CPU Cores utilization while making use of what S.C. alread mostly has, more automatically by option setting. What I've read seems to imply that an instance could run on a different CPU core without special threads programming. At very least, being able to assign or automatically assign full instances to run on different cores or processors (XEONS) could make the effort and expense of extra instances (as they are now) more justifiable/ worthwhile. One poster already suggested something similar to that. A background instance to use a another core (if installed), might focus on datafeed and files-writing while the main installation does calcs, charts, spreadsheets (or vice-versa). That should avoid lag in FAST MARKETS with over 20 charts, many studies each and 7 spreadsheets (for example), or many tick charts, etc.. My I5-2500K's are fast, but watching 3 cores idle at 3% while #3 core jumps to 40%+ at times with S.C. seems a waste of cores' power, since S.C. is already designed for cooperating instances. Even if such a background basic instance option's price was a little more, it would be simpler than installing more instances, whle retaining the multi-install option for very heavy loads as-is (except for CPU cores utilization? |
| [2016-01-28 00:37:25] |
| User704990 - Posts: 18 |
|
Going to a windows OS that utilizes DX12 may be one of the best performance steps you can take assuming you have a decent cpu, etc. Win7 is not an option. Win10 is likely the best choice.
|
| [2016-01-28 02:00:25] |
| User791263 - Posts: 151 |
|
A) I've read the benchmarks on Win7 v Win10. No significant speed improvement vs the trouble. (even slightly slower on about 4 benchmarks). B) DirectX 12 changes are mainly for 3D graphics for Gaming, per https://www.rockpapershotgun.com/2015/09/24/directx-12-games/ I always set 3D to near off and go for intermediate quality on settings for charts. C) DirectX 12 can only be utlized by special Software and vid cards, especially for gaming. Not an issue here. And writing for a particular latest multi-threading gaming graphics software will NOT likely be S.C.'s priority, as they seek simplicity, reliability, speed, and somewhat medium-low-end compatibility (for their least-performance PC medium-level users). Corrolary: That article says that "only Nvidia’s very latest second generation Maxwell GPUs (including the GTX 970, 980 and later) fully support the entire DX12 spec." Thanks though. I'm hoping S.C. might consider a possible option-setting to configure S.C. for multicore CPU's or for a background instance to handle data acquisition (similar to Global Server in old TradeStation 2000i), to offload the chart & calculations instance, and someday an option to utilize another CPU core that way. I think S.C. engineering said above that the best tested configuration was one instance as data feed manager and 2 other instances as all else. It seems intermediate boost would be putting data feed and slow charts on one instance, and fast intraday on another instance is likely to make the intraday much faster. I just wish we could select on option-setting for dual-instance configuration setting, and pay a little more $10 per month for it to be automatic. Or similar. |
| [2016-01-28 19:27:47] |
| User704990 - Posts: 18 |
|
I haven't used dx12 so take what I say with a grain of salt but it seems there are greater benefits then just graphics. But lets assume it is just graphics. If you have a complex chart and reduce horizontal scaling to show many days/bars and then drag the vertical scale you can notice a delay in responsiveness due to the many redraws that need to take place . This doesn't really happen if done with a blank chart. This can also be tried while disconnected from the datafeed. Support has commented numerous times about video drivers being up to date and that video is potentially the greatest load once the obvious factors are considered. **Right from the article you linked, a few paragraphs down... "That means it’s a set of routines and protocols that sit between apps (ie games) and your hardware (ie your CPU and GPU) and define how it all interacts. DX12 covers all kinds of things from audio to 2D video." It would be great to hear Win10 user comments re greater/more balanced cpu utilization with sierra. I always set 3D to near off and go for intermediate quality on settings for charts.
Are you doing this within win advanced sys settings? Cheers |
| [2016-01-29 00:46:36] |
| User791263 - Posts: 151 |
|
Thanks for the description about condensing horizontal axis & redraws required on vertical scale slide. That would likely be a lot of transforming scale calculations. I had not read that about S.C. saying graphics is a heavy portion of the load. A really good 2-D CAD & Trading oriended graphics card might help a lot. On one of our computers, a new 770 upgrade from a 660 (?) cut half the time off of Illustrator files handling. Yes, to turn down 3D, it's somewhere in Display or Advanced settings about Performance, Quality v. Performance, and there's some setting in most AMD & NVidia Control panels to turn 3D down or off. I am now attempting "study precedence" changes by moving most-needed and fast studies up, and think i have screwed something up. Be careful, be sure you are backed up at stages and test each stage! I think that's going to help, however, for more critical fast charts & studies. I'm putting ColorBackgrounds and HiLo for Period near bottom. I wish S.C. could give us a ballpark "relative" Resource Consumption Guide" listing the main types of requirements and component of S.C. vs how that loads performance, such as Size of charts, actual size of windows used, number of sheets or spreadsheets, interconnecting studies on different charts. I just read SC saying that combining studies needed as possible into one chart is often a good idea. (they can correct me). |
| [2016-01-29 01:12:51] |
| User704990 - Posts: 18 |
|
I hadn't heard about moving the studies up/down for precedence in processing, but that makes sense. Along the same line, charts that are furthest left on the chart tab area update quickest, so having a 40ms updating chart on the far right is counter productive fwiw. Also as you likely know, set your longer timeframe charts to ~500ms or greater update frequency. I think the way to do this is to set your deflt update to the higher ms setting, then just adjust your fast charts individually. I plan on doing this over the wkend. For performance I turn everything off, no themes, < 35 processes running,etc. Have you ever considered a pcie nic that has its own processing power to help ease the main cpu load? |
| [2016-01-29 01:43:24] |
| |
|
We are not following this thread too closely, But there is a new feature coming out in Sierra Chart hopefully in another couple of weeks that will allow you to launch a new instance of Sierra Chart with a simple command from the File menu. It will be able to access all the market data and trading functionality in the primary running instance. So this will let you run another Chartbook at the same time using a different CPU core and be able to place that on another monitor. We are also working on the capability to handle file writing, which really takes next to 0% CPU power to begin with, to a background thread. Based on all of our experience and testing this is not going to have any noticeable impact for users. At the current time it is only something that we use in our servers which handle thousands of symbols and very high data rates. In the latest releases, also Spreadsheets are much faster. Most of the CPU load comes from graphics output ( the drawing of the chart). 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-01-30 03:49:19
|
| [2016-01-29 19:05:26] |
| User791263 - Posts: 151 |
|
Exellent Info! Good news for future S.C. Power Users. Thanks S.C.- you guys are Great. Our discussion had homed in on Graphics/chart drawing.re-drawing as likely resource hogs. For Scalpers-Fast traders, much of chart period setting (days) is wasted calcs on 1/2 of charts, because shortest-term charts seldom look back over an hour (many about 30 minutes. Except for long moving averages, such short-term (Tick, Second,1 min charts) could use an option to "calculate to longest study bars only", or as with "Colored Background" (improved), a "bars to calculate" setting could save resources. That might reduce recalc-redraw by 5 or more times. (An SC programmer might add a percentage to that for safety). It is tick and 1-second traders who suffer in a "fast market" if calcs go too many bars back. S.C. advises fast traders to set "days to load" to a minimum. That has helped. (To simulate runs on prior days, load more days). S.C. may have WARNED Users: Do NOT revise your "precedence" study List order if you have many long-built up interdependent charts and studies, study overlays with spreadsheets per chart. I forgot that and had to restore after trying to speed things up that way. THINK precedence when first designing and sequencing studies. Colored Backgrounds, OCHL day lines, horizontal lines, are examples of what can go near end. Spreadsheets automatically cacl after most everything else (very low precedence). |
| [2016-01-30 00:22:43] |
| User791263 - Posts: 151 |
|
S.C. Engineers: While designing such data file write module, consider adding a future alert message text file queue write feature (or write to an alerts spreadsheet would be great, that could output to Excel). The new Data & Files Write module, or something similar might additionally optionally write Alert window messages queue each time it refills (24 records or each X-seconds) to an add-file comma-delimited text file or spreadsheet as above. Such a file could greatly improve access to non-study drawing alerts, via non-S.C. Excel or Perl, etc. programs a user could weight and sum alerts in very useful ways, such as an Excel live-feed chart. Excel could do the actual disk-file writing outside of S.C., from Live comm feed. Or instead of charting or sorting, the output could allow selection of alerts for the user to flag as important (filtering), or which to send via email. (do alerts do SMS text messages yet? Such records could be color coded via formulas, weights, also. An Alerts output file should have configurable additional fields for code-identifying association with each alert, rating, disposition (email, SMS, etc). I suggested such an idea to SC, with conern that S.C. main program writing to a big sequential disk file might impact speed or resources, holding up Main processing (if not done by a semi-autonomous asynch module like you are planning. My system generates up to alert 10 messages per second, but they are not useful as merely a 24-record Alert log window. Messages should not build up in main CPU memory at 10/sec.,so an external file, outputting-adding 24 record (alerts) blocks would be ideal. There are all kinds of useful things that an advanced user could do with that output, making Chart drawings much more useful. A spreadsheet could work with 1000 or so records. |
| [2016-01-30 03:48:43] |
| |
|
In response to post #60 there is a new Window >> Hide Window command which can help for charts that you do not need to look at but are being used in calculations: https://www.sierrachart.com/index.php?page=doc/doc_WindowMenu.html#HideWindow 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-01-30 03:49:49
|
| [2016-04-02 01:37:44] |
| User791263 - Posts: 151 |
|
I've been watching Resources & Cores usage and see better CPU Cores (more equal) utilization lately. Has your work on DTC & Instances included modules flexibility, threading or some way this is occurring? I know the spreadsheets have improved & are faster. You can just tell ( I saw in the Versions notes, too). I have a 4-Core Intel I5-2500K OC'd at 3.9GHZ. On backtesting at 60X speed,or fast market, of cores 0,1,2,3, I'm seeing the middle 2 handling more than the others (way more than a few months ago where most was on one core, a little on another). Even the last core is doing 60% of the main 2. And the 0 core is loafing at about 1/4 of the others. Intel core speed stepping keeps the CPU ususually at a low .96- 1.21 Volts at high load; temp is good even with standard cooler. Maybe I hit a sweet spot on a NV GF GTX 660 (put in a couple months ago) working with On-board INTC 3000 graphics, which seemed to balance out some core load. I'm just curious whether you tried much on threading, or modularity helping the Win 7 64-Pro manage the load? I think SC said the DTC-protocol & server orientation was working toward some threading for the data server? If so, whatever you've done (or we've done) is working. Also I stripped out all the NVIDIA and other junk except the main driver & most basic processes, changed AntiVirus, and set priority to high on SC. Funny-- when I open Chrome with 8 tabs, SierraChart almost loses connection & slows down. Chrome has become a hog. Solution: DO Nothing else with a trading computer but TRADE. Whatever happened, seeing all those cores in balanced load, under 24% total at peak is great on such a huge instance of charts, studies & spreadsheets. Sierra Chart leads the way in fast, reliable, lean & well-designed. |
| [2016-04-02 02:59:08] |
| |
|
I think SC said the DTC-protocol & server orientation was working toward some threading for the data server?
You will only notice a difference when using the DTC Server which occurs when you are running multiple instances of Sierra Chart which you can easily do through File >> New Instance. Make sure you are running 1391 for this. This will be coming out in about an hour. Otherwise, Sierra Chart runs primarily on a single thread after Chartbooks are opened. There will be some transfer of processing to other threads in upcoming versions, but that processing in most cases will be negligible and not noticeable. This involves data feed processing and file updating which in most cases creates no measurable CPU load. 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-02 02:59:58
|
| [2016-04-03 03:46:43] |
| FFTrader - Posts: 180 |
|
Hi all, Since I commented earlier and I was looking to upgrade my trading computer, I thought I can put in my 2 cents now - as I just replaced my old (Intel Core 2 Quad Q6700 based) trading computer with a new computer. Key specifications are as follows: CPU: Intel Core i7-5930K 3.5GHz overclocked to 4.6GHz Cooling: Corsair H100i GTX liquid CPU cooler RAM: 32GB of DDR4-2133 SSD: Samsung 850 EVO 1 TB Sierra Chart instances: 4 instances are loaded together with an IB trading platform (I am using the 1392 pre-release version of Sierra Chart) Takeaway: 1. The overclocking helps a little and noticeably slightly faster chart loading vs. no overclocking. 2. In an ideal condition, with an ambient temperature about 21°C and with some tweaking of the fan speed profiles, etc., the CPU would briefly spikes up to about 75°C and then settles down at around 61°C. 3. As per the attached screen shot of CPU loading at "launch" of all 4 instances, all 6 cores (the other 6 cores are virtual cores - which is why there are 12 charts) are max out for about a minute while the charts loads (chart is of 1 minute interval). 4. As per the attached screen shot of CPU loading when "running" normally of all 4 instances, 2 cores were almost at zero load, 1 core at about 15-20% load (browser?), 1 core at 50% (probably IB platform?), and finally 2 cores at close to max out at 100%. Comment for Sierra Chart engineering: If you are ever going to make Sierra Chart work with multiple cores, please spread out the loading a bit if you can so the cores operating are not constantly maxed out at close to 100%. Just a thought and not a requirement. |
Attachment Deleted.  20160402 Computer load at chart running 1.JPG / V - Attached On 2016-04-03 03:36:32 UTC - Size: 198.65 KB - 656 views 20160402 Computer load at chart launch 1.JPG / V - Attached On 2016-04-03 03:37:12 UTC - Size: 216.07 KB - 713 views |
| [2016-04-03 07:43:26] |
| |
|
Sierra Chart already supports multiple cores/threads in several ways. Chart data loading is on separate cores/threads. Each instance of Sierra Chart is on a separate core/thread. And also, in an upcoming version, market data feed processing and file writing will will be on other cores/threads. Exactly how the threads are allocated to cores is managed by the operating system. Not too sure why you see some cores at 100 percent while running. Are you sure those are from Sierra Chart? 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 07:51:20] |
| FFTrader - Posts: 180 |
|
Well, I can confirm it after further testing. What I am perplexed is that I don't know if there can be non-zero loading. That is, in the example above, essentially I have 4 physical cores running. Not sure why it is not taking advantage of the 2 remaining cores? And SC already support multiple cores? |
| [2016-04-03 12:13:21] |
| User20450 - Posts: 330 |
|
yea FF i have very similar trading comp as u and my chart startups send my cpu into 98% for over a min , not happy about that , new instance help some but not initial load , wonder if there is a way to split data load on ram and cpu better , also maybe have option for bigger charts with more data to not use intra bar tick data , kinda like what TOS does to lighten load , as u can pull up a 20 year chart in less then a second . and not sure if the 32 bit is holding us back either , but sierra ur doing great job to keep up with improvements , thanks
|
| [2016-04-03 21:44:34] |
| |
|
my chart startups send my cpu into 98% for over a min , not happy about that ,
Refer to help topic 30.12:http://www.sierrachart.com/index.php?page=doc/helpdetails30.html#h30.12 as u can pull up a 20 year chart in less then a second .
You can open a 20 year Historical Daily chart in less than a second.Although Intraday charts definitely will take longer. and not sure if the 32 bit is holding us back either
No this does not make any difference,, if anything a 64-bit program could be slightly slower.
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 22:12:59] |
| |
|
kinda like what TOS does to lighten load , as u can pull up a 20 year chart in less then a second
This claim is extremely vague. 20 years of what? 20 years of one minute data? You cannot load that in less than a second and be able to instantly scroll through it. There is no such thing. So these kinds of claim are pointless. In Sierra Chart if you were to set the Intraday Data Storage Time Unit to 1 Minute, you will be amazed at the massive performance improvement you will get. 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 22:48:32
|
| [2016-04-03 22:58:00] |
| |
|
We need to clarify what we wrote in post #70. After some edits, what we were saying was actually describing the issue that post #68 is saying that Sierra Chart should do differently. The point we are trying to make is that there is no way to even load 1 minute Intraday data into a chart and be able to later instantly scroll through that, in any program in less than a second. Sierra Chart can load a year of Intraday 1 Minute data into a chart in about a second. But 20 years is going to take about 20 seconds. Furthermore, if you do want to do analysis on that data which requires tick by tick data, then it is necessary to have tick by tick data there to begin with so it is really pointless to try to use higher timeframe records if later the tick by tick analysis is required when using certain studies. This is the basic problem. If you are using a study which requires the more detailed data, then it has to be there to begin with in the chart. 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-03-28 15:58:22] |
| User921987 - Posts: 234 |
|
Because SieraChart is a fully programmable platform and supports well external data arrays you can allways take a full advantage of all the cores/threads and new hardware features in ýour CPU and GPU (for example via OpenMP and CUDA/OpenCL) by doing all or part of the analysis calculations outside of the direct charting system and bringing in only the results by rendering them on higher time frame charts.
|
| [2019-04-13 02:09:32] |
| whats1thingnow - Posts: 407 |
|
i'm using Sierra Chart Exchange Data Feed i'm seeing huge lags when during US trading hours (e.g. i can see my chart clock tick down every second during off hours... then when market opens, my chart clock skips as much as 4 seconds before updating) You could install multiple copies of Sierra Chart to distribute the processing load. More information about that can be found here:
http://www.sierrachart.com/index.php?l=doc/MultipleServices.html This is going to be the best solution which is available now. So you will have one copy of Sierra Chart that acts like a master, and the others can be slaves receiving data from it. is this still the recommended method to optimize performance? But there is a new feature coming out in Sierra Chart hopefully in another couple of weeks that will allow you to launch a new instance of Sierra Chart with a simple command from the File menu. It will be able to access all the market data and trading functionality in the primary running instance.
So this will let you run another Chartbook at the same time using a different CPU core and be able to place that on another monitor. i'm confused because in the doc (Using DTC Server for Data and Trading in Another Sierra Chart Instance: Using DTC Server for Data and Trading in Another Sierra Chart Instance )it says: Using the DTC Protocol server to share market data and to trade in other instances of Sierra Chart whether on the same computer or different computers, completely replaces the method of sharing chart and market data documented on the Multiple Services page. However, the instructions on that page to install another copy of Sierra Chart on your computer system is still applicable to the method described here.
so if i do File >> New Instance in an existing running instance of Sierra Chart on the same computer using sierra data feed... what is the advantage if any to "install another copy of Sierra Chart on your computer system"??? Date Time Of Last Edit: 2019-04-13 05:04:31
|
| [2019-04-15 11:14:35] |
| |
|
You will want to use File >> New Instance. However, if you have a high CPU load condition within Sierra Chart, then refer to help topic 30: High CPU Usage | Inactive User Interface | Poor Performance | Long Time to Load Chart Data | Charts Reloading Often If you have a problem with too much data being sent on the data feed and there is insufficient network bandwidth causing a delay with the received data, then try using this option: Sierra Chart Exchange Data Feed: Low Bandwidth Option We are locking this 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 Date Time Of Last Edit: 2019-04-15 11:16:42
|
To post a message in this thread, you need to log in with your Sierra Chart account: