Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sat, 27 Apr 2024 04:45:48 +0000
[User Discussion] [Locked] - 32 Bit dll's are fine but I'm having real issues with 64 Bit dll's
View Count: 947
| [2020-02-07 14:37:14] |
| User92573 - Posts: 483 |
|
Dear Support I've finally moved to the 64 Bit Platform and had thought rightly or wrongly, that the 64 Bit would have a lesser impact on my hardware but this is not the case. After re-compiling using same name dll's - all are found by the chartbooks/study collections - however SC has real issues loading even the 32 charts in the test workbook. The 32 Bit works fine (different folder) but the 64 Bit constently fails to respond (Sierra Chart not responding) while loading and reports much higher memory and CPU useage - which is not what I'd expected. During the workbook load I have constant white screens, freezes, delays, a peak useage displayed on the system monitor. After sometime - I get the charts ... until that is I try a replay when it all starts over. Any thoughts? Many thanks. |
| [2020-02-07 19:53:00] |
| |
|
What are the specifications of the CPU on the system? You may need to update your hardware. The 32-bit version of Sierra Chart is still maintained for the time being. 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: 2020-02-07 19:53:14
|
| [2020-02-08 09:08:17] |
| User92573 - Posts: 483 |
|
On this workstation CPU i7 2600K RAM 16GB. I was wondering whether compiling the X64 DLL's via Visual Studio 2017 had any known issues? Many thanks. |
| [2020-02-08 09:50:07] |
| |
|
You may want to use a faster CPU. No known issues compiling with Visual Studio 2017 however it is recommended to use the build functionality within Sierra Chart so optimizations are definitely done. 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 |
| [2020-02-14 01:39:27] |
| User791263 - Posts: 151 |
|
Does 64bit SC take much more resources on load, as post #1 describes? That won't work for my 2 to 3 times larger Chartbook than poster's. Like his, my 32 bit (V1991) loads and runs fast. 2 years ago you said an I7 was plenty fast. A lot of us went with SC for: backwards compatibility, low resources/moderate hardware requirements, stability and leanness /speed. Are those still priorities? SC seems to be moving away from those (our (user)priorites). I'm seeing forced updates/recompiles, less backwards compatibility, poster says lost speed, and you say high-end faster hardware needed. |
| [2020-02-14 04:33:15] |
| |
|
backwards compatibility, low resources/moderate hardware requirements, stability and leanness /speed. This is all absolutely true.But some older hardware is not going to execute 64-bit code as fast. This is strictly a hardware issue. It has nothing to do with Sierra Chart in the least. Not at all. You just have to run your own test and see if your custom studies run the same when built for 64-bit architecture. If your CPU runs it more slowly then your hardware is not well optimized for 64-bit programs. This is all. Our experience is that the 64 build of Sierra Chart is overall faster with memory allocations and releases. We observe no detrimental performance impact. And we are referring to Sierra Chart itself. Not custom studies. The simple fact is the vast majority of our users are not noticing any detrimental impact from the 64-bit version. This is a fact. 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: 2020-02-14 04:34:48
|
| [2020-02-14 05:23:38] |
| |
|
But one thing we would say with absolute certainty, is most likely we are going to enforce a policy that versions less than a-year-old are going to get locked out. Newer versions are so much better than prior versions, there is no reason to be running an older version. We are not going to get ourselves burdened with unnecessary support.
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 |
| [2020-02-14 22:29:13] |
| User791263 - Posts: 151 |
|
You may also tune 64 bit versions (threads, etc) to be faster over time. But "backwards compatibility" is not wiping out non-trade 32 bit 2nd instances with short notice-- when a good "reason" for a work-around (being used) was a spreadsheet compatibility failure of upgrade from V1488-- which conversion takes yet months after months to build a simplified Instance 1 to feed V1488 to be converted. I'm not seeing requests for support on versions over a year; Nobody expects that. Wouldn't it take a couple of hours to add a "Read Only Client" [no trade] server setting to make all of us happy, giving users with larger systems as Instance2 a few more months to figure out how to best convert. A few users could pitch in about $40 each. I would. SC service would look good. [I suggested this in the "workaround" thread: Your Workaround to connect old version to CQG works well; Only backfill a problem | Post: 206823 ] [Ill not pester you. You know what's do-able and right] Date Time Of Last Edit: 2020-02-14 23:05:53
|
| [2020-02-14 23:06:54] |
| |
|
That already exists. You need to set Global Settings >> Data/Trade Service Settings >> Service to No Service. We do not see how it helps to add anything new in this regard since if you want to stay on an older version, any new additions would be on the latest version. 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: 2020-03-24 22:14:09
|
| [2020-02-16 15:50:40] |
| User92573 - Posts: 483 |
|
Dear Support, here is a brief update. I'm currently running Win7 Pro 64 Bit; 16GB Ram; I7 2600K (old but almost as fast as 8700K in tests and runs SC32 very fast .. until recently) Same workbook contents but with appropriate DLL's 32/64. SC 32Bit loads/changes symbol for a line of 8 charts (same studies) in 3 seconds. SC 64Bit loads/changes symbol for a line of 8 charts (same studies) in 11-13 seconds and is completely unresponsive until load is fully completed. System resources are only average which is to be expected with Sierra Charts. RAM does not exceed 50% with CPU'S initially jumping to around 90%. Adding more complex studies results in the resource monitor presenting multiple 'status not responding' messages screen white-outs and system interupts 'deferred'. I'm struggling to understand why the 64 BIT version is taking so long to load when it should be so much faster? I have a 9700K 32GB RAM due on Tuesday but I cant see throwing higher spec hardware given the current use of resources should be necessary. For myself and others who are comitted to Sierra Charts and consider it an excellent platform can you provide any clarity on why this is so? Many thanks. |
| [2020-02-16 20:05:39] |
| |
|
I'm struggling to understand why the 64 BIT version is taking so long to load when it should be so much faster? This is going to be a hardware issue. Microsoft and Intel are best able to answer your question. We simply cannot. We do not have the level of insight that they do. This is not within the scope of our support because this does not have to do with Sierra Chart but rather your hardware.Other than 8 byte addressing with the 64-bit version, the code is completely identical between the 64-bit and 32-bit version. You are asking a question that we don't know the answer to. Understand that. This is not a Sierra Chart specific issue at all. People need to understand 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: 2020-02-16 20:17:24
|
| [2020-02-16 20:47:30] |
| |
|
We ran a test loading a large intraday data file and no studies. This is what we found: The system was a notebook computer with an Intel core I7-6700 HQ with 16 GB of memory. The data file is 1.2 GB. The 64-bit version loaded the file in 1:04 (Minutes:Seconds) The 32-bit version loaded the file in 1:32 (Minutes:Seconds) So as you can see the 64-bit version is actually faster. But why is not something we would know. This is going to be something that only the mainboard manufacturer, Intel and Microsoft can best explain. Logically, from our perspective, we would expect there to be some improvement because there is not any compatibility layer between a 32-bit program and the 64-bit operating system. But we would think that would be a very thin layer where needed. And we would also expect more efficient memory address translations because everything is then handled as 64-bit rather than any conversions. And you should not underestimate the role of the mainboard you are using and the chipset on that mainboard. And if you have the exact opposite result, that really should tell you something is not right with your hardware and it was never optimized for 64-bit to begin with. 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: 2020-02-16 20:49:57
|
| [2020-02-17 21:16:34] |
| User791263 - Posts: 151 |
|
In re your "workaround" to run 32-bit V1488 Instance2 in separate folder...My non-trading V1488 Instance2 (I'm stuck on a few months) has worked so well sharing the Instance1 V1991 server Data folder (when V1488 could connect before forcing us to new version). Above.. you suggest "No Service" setting. That didn't work, probably because all data including ES, MES then comes from SC server instead of Instance2's shared Instance1 data folder? I read that not sharing Instance1 Data folder may be best due to slight "data sharing" differences between versions. Are those differences mainly in trading/positions functions? What about pure Read-only data feed to non-trade Instance2? Should I stop Instance1's server setting and stop using Instance1 Data folder? (ie: Would SC server feed Instance2's own Data folder?) Should Instanc1 stay set as Server to authorize ES, MES, YM, ND intraday data to Instance2 (set "no service"), or is authorization handled by the Global account-broker info? (data would come from SC servers to Instanc2 Data folder?) |
| [2020-03-24 20:28:43] |
| User791263 - Posts: 151 |
|
Please give some clarification to the above #8 and #13 posts. I've been waiting patiently for 5 weeks. The repeating log message forcing update to current has cost me 2 years of work that I can not convert because V1488 "almost runs" but lags 2 seconds each time the message issues. As read-only sub-instance, it ran fine- until that obnoxious message. Since I don't use it for trading and does not need to access CQG directly, and I know it mostly worked via V1991 when no 5-second repeating message issued-- surely you can suggest something. You said each instance logs to broker separately... but then you said try "no service". I just need to know how to make that work, what settings and where to direct the feed (folder) and from where (Main instance V1991 or?), or any details or idea. EDITED: Instance2 V1488 runs a little better, almost normally in SIM mode, served by V1991, even Time and Sales, whereas in live mode there are the 2-second hickups and no time-sales. V1488 SIM still works better than newer versions- Time and Sales goes back properly to a jump-back time. Jump back T&S doesn't work on the newer version, with its' huge screen-hog control. Date Time Of Last Edit: 2020-03-24 22:10:12
|
| [2020-03-24 22:17:20] |
| |
|
Regarding post #8, #13, #14, we do not provide any support for out of date versions or unsupported functionality which you are asking about. If there is anything we have said previously, relating to out of date functionality or older versions, and it is not working as you want, we cannot provide any further help. This functionality is out of date, unsupported, and has not been tested or in use for years, if at all. And most important refer to our post here: Your Workaround to connect old version to CQG works well; Only backfill a problem We have provided you a solution in that post. We have had a solution available for years. It is up to you to use it. V1488 SIM still works better than newer versions- Time and Sales goes back properly to a jump-back time.
We do remember some issue involving the Time and Sales window and jumping back during a replay and that is resolved. The Time and Sales window is more compact from years ago because the buttons are removed and there is only a menu. Also the title bar on it can be hidden.Jump back T&S doesn't work on the newer version, with its' huge screen-hog control. We are not going to post anything further. At this point you are on your own with older versions and with whatever you are doing. This thread is now locked. 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: 2020-03-24 22:19:32
|
To post a message in this thread, you need to log in with your Sierra Chart account: