Support Board
Date/Time: Mon, 25 Nov 2024 16:56:17 +0000
Memory
View Count: 2861
[2013-03-21 21:52:32] |
TastyRisk - Posts: 119 |
Hi there Support, After moving over to the CTS platform, upgrading from around v890 to v951 in the process, I find that SierraChart uses much more RAM. The chartbook that I used with IB data, which utilized about 1.2GB RAM, is too much for CTS/v951! (crashed at around 1.5GB) I estimate that 5GB would be used if I could set-up my desired chartbook. I have 13GB RAM free after loading CTS T4, TWS, Firefox and various utilities... and I suspect that many other users have 8 - 32GB RAM installed... this is considered normal for workstations nowadays. This is my current usage profile (v951 on CTS) 8 x 5 min charts - 5 days to load. 15 x 1 Range charts - 2 days to load. = 1.4GB RAM usage for minimalist setup. I think only a 64 bit application can use 5GB system menory. I would like to continue using SierraCharts and hope that it won't become a legacy application. |
[2013-03-21 22:22:47] |
Sierra Chart Engineering - Posts: 104368 |
This memory usage is not from Sierra Chart. It is from the T4 API. Which we are going to be removing and using a FIX connection. This will dramatically lower memory use. The T4 API uses excessive amounts of memory and CPU usage. We have always known that. Also, we really see no practical reason to support 64-bit addressing because most of the processing goes on within the primary thread for charting and if you really have a lot of charts that require a very large amount of memory. You should distribute the load by running multiple copies of Sierra Chart. Please see: http://www.sierrachart.com/index.php?l=doc/MultipleServices.html Help topic 76 has been updated explaining these additional issues with client-side proprietary API components: Http://www.sierrachart.com/index.php?l=doc/helpdetails76.html Your recent postings have pointed out all of the problems with client-side API components. It's a good example of how code we did not create, provides a very poor impression. 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: 2013-03-21 22:24:11
|
[2013-03-21 22:27:01] |
Sierra Chart Engineering - Posts: 104368 |
Additionally, we have no doubt that in the long-term the outlook of .NET (Used by the T4 API) is questionable. It is a complex, heavyweight, very proprietary Software system created by a disorganized company. This is why we avoid 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: 2013-03-21 23:31:50
|
[2013-03-21 23:37:38] |
TastyRisk - Posts: 119 |
What's the maximum Sierra Chart instance size right now ? |
[2013-03-21 23:38:15] |
Sierra Chart Engineering - Posts: 104368 |
Do you mean the memory? At least 3 gigabytes
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 |
[2013-03-22 00:07:53] |
TastyRisk - Posts: 119 |
I suppose I do mean that, thank you. Do you have a target date for your CTS-FIX implementation ? |
[2013-03-22 00:19:28] |
Sierra Chart Engineering - Posts: 104368 |
Should be within sixty days.
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 |
[2013-03-22 00:30:46] |
TastyRisk - Posts: 119 |
Is this normal? Took a screen shot, timed 60 seconds, then took a second screen shot. See pic. The thing is that it's 2030 ET now. The rate of data growth might be even larger during normal trading hours? The memory usage was over 1GB after the US session but I've since closed the app and started-up again.... with much lower RAM usage. https://www.sierrachart.com/Download.php?Folder=SupportBoard&download=71 |
ramgrowth.png / V - Attached On 2013-03-22 00:30:14 UTC - Size: 64.52 KB - 923 views |
[2013-03-22 01:16:12] |
Sierra Chart Engineering - Posts: 104368 |
It is pointless to comment on this. Excessive memory use does not come from Sierra Chart itself. We have made it very clear the problems with client-side API components: Http://www.sierrachart.com/index.php?l=doc/helpdetails76.html Keep in mind we are very busy. We don't have this kind of time to pay attention of all the little details especially things we have no control over. We have made it very clear we are using FIX and we do not want to hear about further problems with the T4 API. It is pointless at this 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 Date Time Of Last Edit: 2013-03-22 01:17:30
|
[2013-04-18 18:48:09] |
TastyRisk - Posts: 119 |
I really need to be able to use more memory to avoid crashes (see pic). .NET processes are limited to 1.8GB -NOT 3GB. Can you just compile your .NET stuff as 64bit as a stop gap until FiX support? Date Time Of Last Edit: 2013-04-18 18:50:49
|
SC out of mem.png / V - Attached On 2013-04-18 18:47:11 UTC - Size: 30.78 KB - 714 views |
[2013-04-18 19:11:57] |
Sierra Chart Engineering - Posts: 104368 |
Just compile our ".NET stuff as 64-bit". Hardly simple. No chance. We will be starting on T4 FIX in another week or 2 and it should be all done within 2 weeks. 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: 2013-04-18 19:12:36
|
To post a message in this thread, you need to log in with your Sierra Chart account: