normally this can't be:
AMD64 3200, 3GB RAM and MC needs about 30% calculation power of this PC resources to show ONLY an 49 share bar chart on @EC.
In the chart window wasn't ANY indicator. Simple bar chart only!
MC = PC resource feeder???
-
swisstrader
- Posts: 110
- Joined: 16 Nov 2005
- Location: Earth
- Has thanked: 13 times
- Been thanked: 19 times
- Contact:
swisstrader,
as I mentioned in a different thread I am having great problems with MC too when it comes to studies. Running on an AMD 64 4000+ with 2 Gigs of RAM MCActiveX.exe likes to take up 90% of the CPU causing the whole system to freeze for a couple of seconds. You can't trade this way!
Compared to TS it's just a joke and the developers should improve it asap, because this way users will surely not switch from TS to MC.
Chris
as I mentioned in a different thread I am having great problems with MC too when it comes to studies. Running on an AMD 64 4000+ with 2 Gigs of RAM MCActiveX.exe likes to take up 90% of the CPU causing the whole system to freeze for a couple of seconds. You can't trade this way!
Compared to TS it's just a joke and the developers should improve it asap, because this way users will surely not switch from TS to MC.
Chris
-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
-
swisstrader
- Posts: 110
- Joined: 16 Nov 2005
- Location: Earth
- Has thanked: 13 times
- Been thanked: 19 times
- Contact:
-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
Scott, IB is IB. Downloading data from IB is not a question of MultiCharts performance.
It can happen that it doesn't send data to IB's own client just as well (or as bad). This happens - use eSignal if you want a reliable commercial service.
Will work on reproducing the issue reported by swisstrader.
It can happen that it doesn't send data to IB's own client just as well (or as bad). This happens - use eSignal if you want a reliable commercial service.
Will work on reproducing the issue reported by swisstrader.
-
Guest
-
Guest
ScottB,
Alex is right if download the data completely new from IB. It took me three days to fill a data gap of two month on several symbols
.
But MC is still trying to download data from IB for some days although it's already stored in the quotemanager (maybe it's checking if the data is correct). That might cause the problem that you sometimes wait for hours.
Alex is right if download the data completely new from IB. It took me three days to fill a data gap of two month on several symbols
.But MC is still trying to download data from IB for some days although it's already stored in the quotemanager (maybe it's checking if the data is correct). That might cause the problem that you sometimes wait for hours.
-
Guest
Re: MC = PC resource feeder???
I am curious which version you are running. I am not experiencing anything remotely close to this using esignal. I have in addition to my 4 ES charts a Euro chart using 49 vol bars and has 3 months of data. My CPU never gets over 15% However , I am experiencing a lack of responsiveness on occasion that I cannot attribute to cpu usuage. Example , Click to change workspaces and nothing happens. It was like the mouse click was totally ignored as it will not switch. Sometimes it takes two or three mouse clicks. This also happens clicking on other things such as format dialogs etc. Appears to occur totally random.normally this can't be:
AMD64 3200, 3GB RAM and MC needs about 30% calculation power of this PC resources to show ONLY an 49 share bar chart on @EC.
In the chart window wasn't ANY indicator. Simple bar chart only!
J~
-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
Is there a way to keep MC from re-downloading data that is already in the cache? I was told to always use on-demand for a chart.
I use MC to avoid having two data feeds (one IB and one TS) but I would love to speed things up in the initial load. IB can be cranky on session boundaries (ie beginning of day, midnight) and I usually close everything and reopen but the delay is driving me nuts.
I use MC to avoid having two data feeds (one IB and one TS) but I would love to speed things up in the initial load. IB can be cranky on session boundaries (ie beginning of day, midnight) and I usually close everything and reopen but the delay is driving me nuts.
-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
It is a evident that highly compressed charts are slow (when bar spacing is under 1 pixel and the amount of objects simultaneously displayed on screen is huge). The speed of MultiCharts has been tested and found comparable to TS.
In the picture I attached there's an extreme case to demonstrate - a piece of 7 days of @ES 49 volume bars crammed to fit a small window.
No wonder that switching between such windows is terrible and if such a chart constantly updates, it will be constant pain (bar spacing is 0,026 pixels
).
CPU load when displaying this chart is zero, but when I try to compress, expand, move or do anything to it, CPU load instantly goes to 100%.
Switch bar spacing to 1 and speed will be back to normal.
Scott, to your question: use On-line mode in such a case so it retrieves data once and then connects to live data.
In the picture I attached there's an extreme case to demonstrate - a piece of 7 days of @ES 49 volume bars crammed to fit a small window.
No wonder that switching between such windows is terrible and if such a chart constantly updates, it will be constant pain (bar spacing is 0,026 pixels
). CPU load when displaying this chart is zero, but when I try to compress, expand, move or do anything to it, CPU load instantly goes to 100%.
Switch bar spacing to 1 and speed will be back to normal.
Scott, to your question: use On-line mode in such a case so it retrieves data once and then connects to live data.
- Attachments
-
- @es49.png
- (15.31 KiB) Downloaded 2781 times
-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
Then I understand where some of the performance problems come when I overlay charts. But you can't use the 49 Volume Bar spacing if you overlay a 343 volume Chart - you will end up seeing nothing. It's like standing directly infront of the wall and trying to describe the wallpaperGlad this helped, this is something to recommend in all similar cases.
.Chris
Multicore speed benefit
This is an area where having a multicore PC may really help. I use <1 pixel spacing routinely and it has never presented a problem. One core handles the drawing and another the incoming data and analytics. I also have high end graphics cards (NVDA 7800GT), which may contribute.
-
swisstrader
- Posts: 110
- Joined: 16 Nov 2005
- Location: Earth
- Has thanked: 13 times
- Been thanked: 19 times
- Contact:
-
swisstrader
- Posts: 110
- Joined: 16 Nov 2005
- Location: Earth
- Has thanked: 13 times
- Been thanked: 19 times
- Contact:
Alex, please, please think about it, what you have written here.It is a evident that highly compressed charts are slow (when bar spacing is under 1 pixel and the amount of objects simultaneously displayed on screen is huge). The speed of MultiCharts has been tested and found comparable to TS.
In the picture I attached there's an extreme case to demonstrate - a piece of 7 days of @ES 49 volume bars crammed to fit a small window.
No wonder that switching between such windows is terrible and if such a chart constantly updates, it will be constant pain (bar spacing is 0,026 pixels
CPU load when displaying this chart is zero, but when I try to compress, expand, move or do anything to it, CPU load instantly goes to 100%.
Switch bar spacing to 1 and speed will be back to normal.
Scott, to your question: use On-line mode in such a case so it retrieves data once and then connects to live data.
(
small hint for you from my cat: THIS ISN'T THE ISSUE!)
-swisstrader-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
Thanks for the cat photo, but I'm sure that huge amounts of bars with bar spacing under 1 DO slow performance - there is no arguing about this.
If you think there is another issue here, please tell what you suppose it to be.
If you think there is another issue here, please tell what you suppose it to be.
Last edited by Alex Kramer on 03 Apr 2006, edited 1 time in total.
-
swisstrader
- Posts: 110
- Joined: 16 Nov 2005
- Location: Earth
- Has thanked: 13 times
- Been thanked: 19 times
- Contact:
Alex,Thanks for the cat photo, but I'm sure that huge amounts of bars with bas spacing under 1 DO slow performance - there is no arguing about this.
If you think there is another issue here, please thel what you suppose it to be.
what is the difference between a compressed chart and a chart with on day on screen under condition that both charts have the same number of days back loaded? NO difference! The number of informations in both charts are the same.
If you get now a new tick from exchange MC has to add this one information in both charts AT LAST BAR ON CHART! How can this need so much PC calculation power?
I have compare it to TS platform: TS needs about 5-7 % performance under same conditions like in MC.
It seems to me, that the issue is causally in the internal OS of MC and with every tick MC updates the complete loaded bars of chart window. (only a guess).
Same with PLEditor crash: after open the editor and work so about 2-3 mins with the editor he reacts immediately on the shortest mouse move on table and will close by this mouse movement. Try it: open PLEditor, and wait 2-3 mins. Then take the mouse in your hand and move it.
-swisstrader
-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
> Alex, what is the difference between a compressed chart and a chart with on day on screen under condition that both charts have the same number of days back loaded? NO difference! The number of informations in >both charts are the same.
This is a mistaken assumption. While the number of bars is the same, the system performance is heavily affected by the number of objects (bars, drawings, lines etc.) on the same screen. Same goes for screen resolution –the higher resolution, the worse performance. This is related to various technical aspects, one of which is optimizing the video output and rendering the active screen.
>If you get now a new tick from exchange MC has to add this one information in both charts AT LAST BAR ON >CHART! How can this need so much PC calculation power?I have compare it to TS platform: TS needs about 5-7 % performance under same conditions like in MC.
Please compare apples with apples. You can’t compare fairly since TS doesn’t allow you to squeeze charts as MC can. I assume it works this way to provide good performance which is not possible with high compression.
>It seems to me, that the issue is causally in the internal OS of MC and with every tick MC updates the complete loaded bars of chart window. (only a guess).
It is not correct. Run a simple test – create a chart with a million bars. Allpy a complex study requiring 30 seconds to calculate. According to your assumption, now on every tick arrival the study must take another 30 seconds to recalculate – that is not so.
>Same with PLEditor crash: after open the editor and work so about 2-3 mins with the editor he reacts immediately on the shortest mouse move on table and will close by this mouse movement. Try it: open PLEditor, and wait 2-3 mins. Then take the mouse in your hand and move it.
The Pleditor crash has no relation to this whatsoever, it’s a separate issue we acknowledge and will soon fix.
This is a mistaken assumption. While the number of bars is the same, the system performance is heavily affected by the number of objects (bars, drawings, lines etc.) on the same screen. Same goes for screen resolution –the higher resolution, the worse performance. This is related to various technical aspects, one of which is optimizing the video output and rendering the active screen.
>If you get now a new tick from exchange MC has to add this one information in both charts AT LAST BAR ON >CHART! How can this need so much PC calculation power?I have compare it to TS platform: TS needs about 5-7 % performance under same conditions like in MC.
Please compare apples with apples. You can’t compare fairly since TS doesn’t allow you to squeeze charts as MC can. I assume it works this way to provide good performance which is not possible with high compression.
>It seems to me, that the issue is causally in the internal OS of MC and with every tick MC updates the complete loaded bars of chart window. (only a guess).
It is not correct. Run a simple test – create a chart with a million bars. Allpy a complex study requiring 30 seconds to calculate. According to your assumption, now on every tick arrival the study must take another 30 seconds to recalculate – that is not so.
>Same with PLEditor crash: after open the editor and work so about 2-3 mins with the editor he reacts immediately on the shortest mouse move on table and will close by this mouse movement. Try it: open PLEditor, and wait 2-3 mins. Then take the mouse in your hand and move it.
The Pleditor crash has no relation to this whatsoever, it’s a separate issue we acknowledge and will soon fix.