MSM Load Time

[michaelthomas]

Hi, I just recently installed MSM 2.0.

I'm running Mach3 3.043.062
KFLOP latest Plugin
Windows XP 32bit
1.66Ghz dual core 1GB Ram laptop

When I try to load Mach, it takes about 25 seconds. After it is loaded, if I try to use a wizard......it takes about the same time to return to the MSM screen from the wizard.

Is this normal?

Mike

[DaveCVI]

Hi,
I'm on a biz trip, please excuse the brief response. The short answer is "yes" - the load time is very dependent on the PC in use (both CPU speed and disk access speed). What you report for elapsed time is about 2x-3x what I normally see. Exiting a wizard causes mach to reload the prior screens from scratch (mach is not smart enough to cache anything and it loads everything al the time no matter what is actually needed ti show the first page).

please see this thread for some more info:
calypsoventures.proboards.com/index.cgi?board=msmsupport&action=display&thread=178

Dave

[michaelthomas]

Hmmm.....OK

So what would be the optimum pc setup to get the load times down to a liveable 5-8 secs?

How many cores will Mach 3 use?

I tried MSM out on a desktop single core 2.8Ghz and it was about 19 seconds compared to the actual measured 28 for the aforementioned laptop.

I would be willing to get more cores if need be, but for the most part they have never helped me for most of the stuff I run. (Rhino).

I have a 3.4Ghz single P4 I could try, too.....but it doesn't stand to reason that it will be 60% faster than the 2.8 P4, which is about what I would like.

None of my computers are running any antivirus, and they have very minimal installations that may be doing something else.

More cores at the higher clock speeds must be the answer......but what is the most that will actually be used?

I don't want to spend any more than I need to.

You have done a nice job on this screenset......really nice.

Mike

[DaveCVI]

Hi Mike,

OK, here are some thoughts on things that might speed up mach's screen set loading. I want to state very clearly up front that these are ideas and NOT things I have tried and tested. If you choose to explore these ideas, I'd be interested in the results of the experiment - but I can't be responsible for any time and $ expended along the way. I also can't (and won't) be responsible for PC config problems that could result.

OK, with that understanding, here are some thoughts:

1) mach gets fixed
This is the real, correct and preferred way to fix the load speed. Alas, the only person that could do this is Brian at Artsoft, but he's had this on the todo list for over 2 years and still has not gotten around to it. So I'm not holding my breath on this approach. The load problems are more that just time it takes - there are other mach bugs in this area (see the MSM release notes)

The rest of these are ideas based on what I think mach is doing based on info gathered from Brian and Steve -

A) I don't believe that multiple processor cores or even more processors will help here. Mach is basically a single thread application when loading and can't make use of any other cores. So paying for more cores will not help.

B) raw processor clock speed for the single cpu being used could help - but this would only be true if the ultimate bottle neck is cpu power.
Since I do see different load times on different processors, the load time is dependent on CPU speed, but I suspect that the real problem is a PC's IO speed.

For context one has to understand how mach set files are structured:
The set file is a set of sequential records that Mach processes one by one. any record that has a bit map reference causes the bit map to get created in memory - in case mach ever needs to display it. This is the first major problem: mach renders everything that might be used on first load and has no concept of only loading up what is needed, as it is needed.

The 2nd problem is that if a single bit map is used multiple times, mach reads and loads it multiple times. Neither the set file structure nor mach are aware of the concept of common information.

3rd, the 1024 screens load quickly as they essentially have no bitmaps - they just use the default buttons (which are a constant single color background) and no 1024 pages have background bitmaps. The result is faster load and the cost is, well, the (IMHO ugly) stock screen set appearance.

This means that the loading of a bitmap based set file, causes mach to access many different small files, each of which mach loads into memory.

c) turning off antivirus programs can significantly speed this up as the AV processing takes a lot of time for each file open operation. I have seen this effect make a big difference. Of course turning off AV can have other negative consequences.... that may be Ok for a PC dedicated to only machine control, but may not be a good idea for a general PC connectd to the net....

The following will not likely help you as you said you are already not running AV on the control PC:

Another area of experimentation would be to see what impact using different Av programs has - they vary widely in terms of how much they load up a PC. But this is PC config experimentation and not something that I would recommend for casual PC users (multiple AV program can hard crash a PC)

d) All this file access probably means that the load time could be limited by the IO performance of the PC, particularly wrt to HDD access etc.

I've thought about creating a RAM disk and moving the mach and MSM install to the ram disk. I'd be interested in knowing what impact that might have.

Another idea would be to see what the difference is between a common rotating HDD and an SSD (solid state disk).

However, again this is in the realm of PC optimization. The complex interactions between RAM disk and Windows caching mechanisms is a topic that I can't get into as a MSM support side effect.

In general, CVI can't support a PC optimization experiment as part of MSM support (it's just too likely to create PC problems ).

If you do want to experiment, I'd like to know what you learn, but you will have to be on your own for the experiments.

Dave

[michaelthomas]

Dave,

Thanks for the reply.

What are the load times that are typically seen?

From an earlier post you referenced, I was guessing 10 seconds or less.

I'm not going to experiment much more than I have.....I was just trying to get an idea of what others were running that gave them faster load times. If I didn't use wizards, I wouldn't even care how long the initial load took.

For what its worth, I disabled hyperthreading and found that it added another 20% of time to the load. This is what made me think more cores might help.

I'll see how my 3.4 does today.

Mike

[thosj]

FWIW, Core2 Quad Q6600 at 3Ghz (oc'd slightly), 4GB RAM, Win7 32, WITH an OCZ Vertex 2 SSD, and MSE antivirus, from double click of a Mach3 desktop icon to ready, 17 seconds. This is on my test computer running LOTS of stuff in the background.

The control computer, Core i5 2400s, 4GB of faster RAM, Win7 32, SSD, but with lots less running in the background, with Vipre AV instead of MSE, loads in 23 seconds. Faster proc (?), longer load.

So there MAY be something to the AV running on the PC.

I don't use wizards so no experience, initial load times not an issue for me.

Both my computers are networked and hooked to the internet. I've taken much grief about this practice, but continue to do it regardless!! Too handy, and NEVER a problem.

[DaveCVI]

Hi,
The reason wizards aggrebate the situation is that when a wizard exits, mach reloads the primary screen set from scratch - mach has no smarts re caching the screen set info for reload...

Dave


Sent from smart phone, please excuse brevity & typos

[michaelthomas]

Thanks for the load time info......its nice to have something to compare to.

So after trying my 3.4Ghz box today and not getting much better results.....I began to try some other Mach settings.

If I uncheck auto screen enlarge, Hi-Res Screens, and the boxed DRO.....my load times drop to about 6 seconds from 17 or so on the 3.4.

I can't really see a lot of difference with the Hi-Res screen checked anyway.

With one of my old school 1280 x 1024 monitors, I can run the larger screen and it fits pretty well in the space without auto enlarge. I guess I'll just use that one on my machine.

Even my anemic processored 1.66 laptop got below 10 seconds.....and it could be as slow as 30 seconds, otherwise.

Interesting, anyway.

Mike

[DaveCVI]

Mike,

Ah.....

From the MSM user manual section 1.4.1:

"While MachStdMill will happily run with whatever combinations of Mach settings you use, we do recommended settings for a couple of the “Mach General config” options.

To see the designed MachStdMill appearance, in the Mach General config dialog box (accessible from the Mach menu bar) set:
Auto Screen Enlarge = Off
Boxed DROs and Graphics = Off
Hi-res screens = Off"

I really hate that bleeping "Auto screen enlarge" option - it really, really should be named "Auto distortion". It attempts to re-sample a fixed bitmap to make it "fit" the physical screen resolution. That means that not only is mach loading lots of bit maps, it's also trying to redraw each one at the same time.... and anisotropically distorting the images in the process - and that all takes CPU time.

Using the 12x9 screens on a 1280x1024 monitor is a much better solution - not only will the graphics not be distorted, mach will load MSM faster. I am a bit surprised at how much time you gained - I didn't think it would be that much - thanks for the report.

Dave

[michaelthomas]

I'm actually planning to read that manual here pretty soon.

Mike