MC = PC resource feeder???

Questions about MultiCharts and user contributed studies.
User avatar
swisstrader
Posts: 110
Joined: 16 Nov 2005
Location: Earth
Has thanked: 13 times
Been thanked: 19 times
Contact:

MC = PC resource feeder???

Postby swisstrader » 30 Mar 2006

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!
Attachments
resources feeder.PNG
resources feeder.PNG (48.27 KiB) Viewed 785 times

Chris
Posts: 150
Joined: 17 Nov 2005

Postby Chris » 30 Mar 2006

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

User avatar
Alex Kramer
Posts: 834
Joined: 23 Feb 2006

Postby Alex Kramer » 30 Mar 2006

This hasn't been reported before...
What version are you using? How many bars in that chart? Also, could you please send an example workspace that shows such behavior?

User avatar
swisstrader
Posts: 110
Joined: 16 Nov 2005
Location: Earth
Has thanked: 13 times
Been thanked: 19 times
Contact:

Postby swisstrader » 30 Mar 2006

you can build the workspace yourself:
open a simple chart window with data feed by TS:
symbol @EC and 49 share bars with 7 days back
THAT'S ALL. no indicator, no other program opened,
used last version 1.90.449.1165

ScottB
Posts: 13
Joined: 13 Mar 2006
Location: US

Postby ScottB » 30 Mar 2006

I have 2 G of ram and 3.06 dual core and it can take an hour for a chart to load from IB. I am getting data only from the first of March and I literally start the chart and go do something else. It too is taking 80 - 100% CPU at times.

User avatar
Alex Kramer
Posts: 834
Joined: 23 Feb 2006

Postby Alex Kramer » 30 Mar 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.

Guest

Postby Guest » 30 Mar 2006

Alex,

I have an in-house application that loads the same data in seconds. In fact, if I start the in-house before MC, it will download the data in seconds and then start MC which may take an hour.

Guest

Postby Guest » 30 Mar 2006

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 :lol: .
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???

Postby Guest » 30 Mar 2006

swisstrader wrote: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!


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.

J~

User avatar
Alex Kramer
Posts: 834
Joined: 23 Feb 2006

Postby Alex Kramer » 31 Mar 2006

We'll test this issue and monitor CPU load thoroughly, thanks everyone for the attention.

ScottB
Posts: 13
Joined: 13 Mar 2006
Location: US

Postby ScottB » 31 Mar 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.

User avatar
Alex Kramer
Posts: 834
Joined: 23 Feb 2006

Postby Alex Kramer » 31 Mar 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 8) ).
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
@es49.png (15.31 KiB) Viewed 782 times

ScottB
Posts: 13
Joined: 13 Mar 2006
Location: US

Postby ScottB » 31 Mar 2006

Thanks Alex, that did it - it loaded in about 2 seconds

Scott

User avatar
Alex Kramer
Posts: 834
Joined: 23 Feb 2006

Postby Alex Kramer » 31 Mar 2006

Glad this helped, this is something to recommend in all similar cases.

Chris
Posts: 150
Joined: 17 Nov 2005

Postby Chris » 31 Mar 2006

Alex Kramer wrote:Glad this helped, this is something to recommend in all similar cases.


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 wallpaper :wink: .

Chris

trader39
Posts: 92
Joined: 08 Jan 2006
Has thanked: 8 times
Been thanked: 4 times

Multicore speed benefit

Postby trader39 » 02 Apr 2006

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.

User avatar
swisstrader
Posts: 110
Joined: 16 Nov 2005
Location: Earth
Has thanked: 13 times
Been thanked: 19 times
Contact:

Postby swisstrader » 02 Apr 2006

OK., let's buy tomorrow a CRAYSTATION and all is solved!

:lol:

User avatar
swisstrader
Posts: 110
Joined: 16 Nov 2005
Location: Earth
Has thanked: 13 times
Been thanked: 19 times
Contact:

Postby swisstrader » 02 Apr 2006

Alex Kramer wrote: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 8) ).
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.


Alex, please, please think about it, what you have written here.
( :idea: small hint for you from my cat: THIS ISN'T THE ISSUE!)

Image

Image -swisstrader

User avatar
Alex Kramer
Posts: 834
Joined: 23 Feb 2006

Postby Alex Kramer » 03 Apr 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.
Last edited by Alex Kramer on 03 Apr 2006, edited 1 time in total.

User avatar
swisstrader
Posts: 110
Joined: 16 Nov 2005
Location: Earth
Has thanked: 13 times
Been thanked: 19 times
Contact:

Postby swisstrader » 03 Apr 2006

Alex Kramer wrote: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.


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.
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

User avatar
Alex Kramer
Posts: 834
Joined: 23 Feb 2006

Postby Alex Kramer » 03 Apr 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.


Return to “MultiCharts”