the 3GB Switch?

I know this was discussed already many times in this NG, but I can't find
those posts..... How do I set SolidWorks to be able to use 3GB of memory?

Thanks,
Gil

 

Dear Gil,

Here is that mail I recevd a long ago, I hope it will be useful to you

The Perils of Trying to Overcome the 2GB Memory
Limit - Part I

By Ed Eaton

(Editor's Note: The top tip of 2004! This three-part series was by far
the most popular user tip of last year. We thought it deserved a
reprint for those who may have missed all or part of it. Ed Eaton kicks
it off with Part 1. Check back next week for Wayne Tiffany's
continuation in Part 2).

If you crash SolidWorks or PhotoWorks because of insufficient memory,
purchasing more RAM for your computer is only part of the solution.

No matter how much memory you have, or how big your virtual memory,
Windows will not allow you to use more than 2GB for a single
application.

On top of that, the 2GB is theoretical. In practice, applications crash
when memory usage reaches about 1.6-1.7 GB. This of course will stop
you cold if you are working on large assemblies, or on PhotoWorks
renderings.

Because of the 32-bit operating system, the mathematical limit for
total memory (physical and virtual memory) is 4GB. By default, Windows
reserves half of that total for itself!

SolidWorks is written to take advantage of the 3GB switch. This switch
allows Windows XP Pro and some server applications to override the 2GB
limit and free up to 3GB of that expensive RAM you've been buying for
your systems.

Unfortunately, when our company attempted to follow the instructions as
presented, we permanently prevented our system from rebooting.

After a great deal of extra research, we found that enabling the 3GB
switch requires that you know a poorly documented two-step process.

The first poorly documented problem is that the 3GB switch is not
working in Windows XP Pro, Service pack 1 (that's why the system locked
up)! To get a hotfix that corrects the issue, you have to call (800)
936-4900 and get to the "hotfix" people. Don't get spooked by
Microsoft's statement that they will charge $245 for tech support -
hotfixes are free.
Let the person on the phone know the problem has to do with the 3GB
switch.

The link for that article is
http://support.microsoft.com/default.aspx?scid=kb;en-us;328269&Product=winxp.
Microsoft will e-mail you a hotfix that carries no warranty and is not
recommended for use in a production setting unless you thoroughly test
it. But, for the record, it worked for us, and I have not experienced
any problems in the three months I've had it on my machine.

After running the hotfix, enabling the 3GB switch is not as simple as
checking a box in a dialogue. You have to dig into your boot.ini file
and modify it.
The boot.ini file is on the top level of your C: drive, but to make it
visible you have to go through Windows Explorer Options, Tools, Folder
Options, View and select "Show hidden files and folders" and deselect
"Hide protected operating system files."
The text of your boot.ini file may not match the sample shown. For
reference, here is what I had to do with my boot.ini file:

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP
Professional" /3GB /fastdetect

A final warning: Yes, enabling the 3GB switch has worked for us and
allows us to use up to 2.7GB of RAM before locking up SolidWorks or
PhotoWorks. We are now able to perform tasks that were simply not
possible before the modification. But as with any time we hack our
systems for performance, there are risks. Before starting on this
process, I made a complete backup of my boot drive than I could plug in
and use if things went south.



The Perils of Trying to Overcome the 2GB Memory
Limit - Part 2

By Wayne Tiffany

Editor's Note: The top tip of 2004! This three-part series was by far
the most popular user tip of last year. We thought it deserved a
reprint for those who may have missed all or part of it. Ed Eaton
kicked it off last week with a discussion of utilizing the 3GB switch
with Win XP. This week, Wayne Tiffany follows up by trying the 3GB
switch on three machines with precious little RAM. Check back next week
for Wayne's thrilling conclusion in Part 3.


I had read a bit about the 3GB switch in the past, but never really
pursued it. However, after reviewing Ed's article before publication,
it occurred to me that maybe this would even help a machine with only
1GB of physical memory, and this information would be a valuable
addition to the article. So I asked Ed - he didn't know.

The next logical step, then, was to figure out if there could be any
benefit to a machine without gobs of RAM. The thought of a virtually
free "upgrade" intrigued me, so I decided to find out.

The testing was all carried out by telling SolidWorks to load a huge
file - certainly more than could be expected to fit, and was run on the
different machines with various configurations. At the point that
SolidWorks gave up due to lack of available memory, the amount utilized
was recorded. Then the machine was rebooted and the next iteration was
run.

One very important point to make - heed Ed's advice about applying the
patch to WinXP SP1. If you turn on the 3GB switch without the patch,
the machine will not boot! How do I know for sure?

Embarrassingly, I must admit that in my exuberance to pursue more
positive results, on one machine, I turned on the switch before the
patch. Not so bad, I figured, just boot on a DOS floppy and modify the
boot.ini file again. However with the SCSI drive in the machine, the
drivers didn't load with the DOS boot, so the C drive was not
accessible. The get-it-running-again solution was to install the hard
drive on another machine as a second SCSI drive, and edit the boot.ini
file from there to turn off the 3GB switch. Then back to its home, and
this time, do it right. Note: you don't have to find & edit the
Boot.ini file by itself with a text editor; you can do it through
Windows by doing a right-click on My Computer, then selecting
Advanced/Startup and Recovery Settings. There you will see a line that
says, "To edit the startup options file manually, click Edit." Click on
the button and it opens the file for you.

So, take a look at the results (the number recorded is the Total amount
of RAM in the Commit Charge box), and decide if this is something you
want to try. The bottom line of my testing was that making the changes
did, in fact, give SolidWorks 2004 another GB of working space, even on
a machine with only 1GB of physical RAM. Not as fast as having 4GB of
physical RAM, but it may make the difference between actually getting
something to load, or having it crash and burn. One final note -
COSMOS will not recognize the extra memory yet, but hopefully will for
the 2005 release.

Dell 360, 3.0Ghz, 2GB RAM, swap file set to 2046K min - 4092K max:
SW2003 3GB switch off 1.98GB
SW2003 3GB switch on 1.99GB
SW2004 3GB switch off 2.00GB
SW2004 3GB switch on 3.00GB

Dell 350, 2.8Ghz, 1GB RAM, swap file set to 3072K min - 3072K max:
SW2004 3GB switch off 1.71GB
SW2004 3GB switch on 2.79GB
SW2004 3GB switch on 2.81GB (Set the max swap file limit to 4098 just
to see)

Dell 350, 2.8Ghz, 1GB RAM, swap file set to 3072K min - 4098K max (a
different 350 machine):

SW2004 3GB switch off 1.71GB
SW2004 3GB switch on 2.80GB
SW2004 3GB switch on 2.85GB (Upped the physical RAM to 2GB)




Wayne Tiffany is a Senior Design Engineer at Automatic Systems, Inc. in
Kansas City. He is currently the CAD manager for SolidWorks there and
has more than three years of SolidWorks experience designing custom
machinery for the conveyor and automotive industries. He is the current
president of the Kansas City Area SolidWorks User Group, and is a
Certified SolidWorks Professional. Wayne can be reached here.



The Perils of Trying to Overcome the 2GB Memory Limit - Part 3

By Wayne Tiffany

I've been investigating the 3GB switch some more and learned a few more
valuable pieces of the puzzle. If you missed the first two
installments, here are the links to them - it's worth reading them
first to know what's going on. Then you can also search the newsgroup
comp.cad.solidworks for "3GB" to read more discussion on the topic.

Part One can be found here

Part Two can be found here

Probably the most important discovery is that while you can turn the
switch either on or off, you can also set how much memory you want to
allocate - it isn't all or none as I had thought. When I turned it on
full bore, I experienced problems connecting to network drives. Huh,
you ask? The error message reads "Z:\ is not accessible. Insufficient
system resources exist to complete the requested service."

So what's this have to do with the switch? Keep in mind that turning on
the 3GB switch "steals" memory away from the XP operating system and
"gives" it the application side. I don't know if there's something
peculiar about my particular computer/network/XP version, etc., but
apparently something doesn't work properly when I steal the whole GB of
memory.

So, what's the secret? In the Boot.ini file you can set another switch
that controls the amount of memory allocated to the application. Here's
my Boot.ini file as I am now running. (For more information on switch
options for WinXP Boot.ini file, go to
http://support.microsoft.com/default.aspx?scid=kb;en-us;833721&Product=winxp.)

[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP
Professional 3GB limited" /fastdetect /3GB /userva=2900 /SOS
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP
Professional" /fastdetect /SOS
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP
Professional 3GB " /fastdetect /3GB /SOS
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP
Professional 4\3GB " /fastdetect 4\3GB /SOS

If you look at the [operating systems] section, you will notice that I
have 4 entries - all different. This gives me four different boot
choices if that option is turned on. (Check the box and set the time.)
Take a look at the part in quotes right after the WINDOWS=. If you read
the Microsoft info, you are led to believe that the only verbiage that
can be there is from a set list of possible operating systems. Not true
- when I did that, all the presented options looked the same, and I
couldn't tell which one was which. So, customize the list. I haven't
tried totally varying from the list, but what you see here does work.

The first option is the default that I am currently running. Notice the
"/userva=2900" in addition to the "/3GB " at the end - the value is
the amount of RAM that is allocated to the application side. I started
at 2.5 GB by setting it to 2560. Here XP worked OK, but I hit the wall
with SolidWorks, so I bumped it to 2816 - same story. So then I
wondered if maybe the difference might be just the fact that I enabled
the /userva switch; Nope, setting it to the full 3072 once again gave
me the XP problems. I set it to 3000 and ran there for quite some time,
but then did eventually get hit with the XP error message again;
therefore the 2900 value. Where's the exact upper limit? I don't know
- haven't had the time to tweak it closer. Your mileage may vary.

The second line is the "standard" line and is quite valuable to have
there in case something goes wrong - like not installing the XP patch
first. The third line, of course, is the full 3GB allocation. The
fourth line is what Mike Eckstein was told to do with his machine, but
I never could see any difference in the way the machine ran with
"4\3GB" vs. "/3GB".

So, the bottom line is, if you are constantly working in the 2.0 - 2.5
Commit Charge range, as I currently am, and just turning on the 3GB
switch causes other problems, this latest info will probably let you
open up enough more memory to get the job done.

Wayne Tiffany is a Senior Design Engineer at Automatic Systems, Inc. in
Kansas City. He is currently the CAD manager for SolidWorks there, and
has more than four years of SolidWorks experience designing custom
machinery for the conveyor and automotive industries. He is the current
president of the Kansas City SolidWorks User Group, and is a Certified
SolidWorks Professional.


Regards

Deepak Gupta

 

http://www.kcswug.com/documents/3gb_switch_part_one,_two,_&_three.pdf

WT

 

sorry forgot to poste the links

part one: http://www.swcommunity.com/feature_full.php?cpfeatureid=4372

part two: http://www.swcommunity.com/feature_full.php?cpfeatureid=4475

Regards

Deepak Gupta

 

Deepak,
Thanks for replying.
According to Wayne's and Ed's descriptions and details -this sounds pretty
spooky!! I think I've got cold feet, and will not attempt to mess with the
boot.ini file, it just sounds too scary!

Thanks anyway,
Gil

 

Wayne,
Thanks for the detailed info!

However I have some further questions:

A. If I turn the 3GB switch, and it messes my system, can I still load
Windows XP pro SP2 using safe mode?

B. As I understand with a computer with a 64 bit processor who can access
16GB of RAM and Windows XP pro 64 bit OS, SolidWorks 64 bit can access more
then 4GB RAM. is this correct?

I have to admit that in the mean time I've got pretty cold feet and
considering more seriously if should attempt to set the 3GB switch, because
it is the first photoworks/animator job where I have an assembly with almost
80 parts, most of them refracting and reflecting, which should last for 25
seconds in 15 fps rate@ 740*480 resolution.

For some unexplainable reason (because I consider myself with too little
knowledge on OS and memory issues) I feel that SolidWorks is handling memory
in a very poor way.........is my feeling correct or am I totally wrong in
this direction? although I know that solidworks is a very complex program
which suppose to use many resources, it still seems to me way too
much..........

I know you are not a SW employee but wonder if you know the answer to this:

Doesn't SolidWorks suppose to free memory which it doesn't need anymore, and
be able to use this memory space again?
I mean that when I render using PhotoWorks and Animator a 3 seconds film
with 30 frames totally, the resultant AVI file is less then 1 MB, but my
computer reaches page file usage of 1.6GB!
And what is almost more peculiar is that at the end of the rendering
process, when the computer is idle again and SW still works the page file
keeps this huge size, but if I close then solidworks, then the task manager
reports page file usage of only 200MB!!

Thanks,
Gil

 

PS this was sent to me and is not my own work.

 

I have been using the 3 GB switch for over 2 years now and have not had any
issues.
Here is a copy of my boot.init file file. Notice the last 2 lines are
identical except for the "3gb". At start up you will be given the option of
2 different operating parameters, one with 3gb, one without. The options
will read the same at boot, but put the 3gb line before the one without 3gb
in the init file and it will be the default startup. If you ever need to go
back to the original setup highlight the lower line at boot and hit "enter"
..

[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional" /fastdetect /3gb
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional" /fastdetect

Good Luck
Mike

 

First off, go for it!

Now, that being said, let's talk a bit to relieve some of your fears. The
biggest risk is if you are not running XP SP1 and you forget to apply the
patch. But I would presume that you are already on at least SP1, so that's
not an issue any more.

So, be brave, edit the boot.ini file by adding the one line as directed in
the instructions, and go for it. The nice thing about adding a line rather
than modifying the only existing line is that you can still boot on the old
setup if something doesn't work quite properly.

To answer your questions, a safe mode boot would not work if you don't have
XP SP1 and you forget the patch. Other than that, it should.

XP64 can address more than 4Gb of address space, so the 3Gb switch doesn't
apply.

I don't know for sure how the page file allocation is handled, and it may be
that once it is expanded, it stays allocated until that program closes. I
wouldn't worry about that too much as it's space on your hard drive, and as
long as you see it go down when you close SW, it's probably working
properly.

Just remember that changing the boot.ini file always has the possibility of
making your machine unbootable, but it's not fatal. So, follow the
directions carefully and you should be just fine. Let us know how you get
along.

WT

 

well.....I did it........and world didn't go under ;-), thanks for giving me
the courage, Wayne!
Now I need to see how this will affect my overall computer performance and
SolidWorks performance.

One further question regarding XP64: do you happen to know how much memory
does this OS give to applications?

Cheers and thanks again,
Gil

 

Thanks Mike,
I did it, and it works until now fine!

Cheers,
Gil

 

I don't know for sure how the page file allocation is handled, and it may

Wayne,
I decided to investigate in this matter of exaggerated page file size while
doing the animation rendering, and showed it to my brother who is a
programmer and deals a lot with OS management and programming:

He told me that what The task manager shows is completely not normal for an
application like solidworks combined with animator and photoworks. he says
that the fact that the page file increases endlessly further and further as
solidworks continues with the rendering job indicates of something which is
called a "Memory Leak", which to his opinion is definitely a bug and should
not happen. so I guess the only option is to hope SW will release another SP
and fix this with it or at least have fixed it for SW2007.

Anyway, in this particular case setting the 3GB switch will not help as
much. it just postpones the critical second where SW announces that it ran
out of memory, to a later stage of the animation rendering job.

Cheers,
Gil

 

I'm glad you posted that because it will lend some credibility to my
observation that Solidworks has had a memory leak issue for years. I don't
know how it's possible, nor why it can't be fixed but I've been working in
Solidworks since version '98 and you can predict with staggering accuracy
when it it will crash to desktop and under what conditions. The versions
from 2003 on were the worst, with (for me anyway) 2006 being the medal
holder for all time worst, with '05 close behind.

Until 2001 I was in charge of Solidworks for a large group of design
engineers, including myself, and then in 2001 I incorporated my own design
firm and chose Solidworks. I've seen it run on countless machines under
very controlled conditions, especially in my own company and its amazing.
Memory leak is not a term that should exist for established software yet
it's still there. I've switched to '07(sp1) a couple weeks ago because '06
was the worst I've ever seen. In our small office you could hear the
Windows XP crash sound about 2-3 times per day reliably. I swear it's
better in '07 but we've stilled crashed it. For us, Solidworks "major"
issues boil down to this... 1) pesky memory problems (or poor use). If
it's not a memory leak then it's just plain bad memory management. I
suspect they don't properly release memory when closing files. In other
words, the more parts and assemblies you open the more memory that gets
taken up, obviously, but closing files doesn't reliably reduce the
saturation. Is that a leak technically, maybe not but the result is the
same. Boom, say hello to my little desktop. 2) network issues. It's no
surprise that SW works better with all files local but for any collaborated
workgroup that is not a good option. It's an option but not a good one.
Even with dead-nuts reliable high speed low latency gigabit networking SW
still has a problem with network operation. After this many years of being
an "expert" I still can't put my finger on what or why but we've all fealt
it. I've had a top notch app engineer in from our Var a couple times and
our ship is tight. Analogously it's like data is flying through an
intersection and gets broadsided by other data. Again, you can feel it
coming. Hit or miss, but when SW has to wait too long for an expected piece
of data it smacks a wall. And finally 3) Toolbox. What can I say that
hasn't already been said. Toolbox is the best example of how to make the
worst of points 1 & 2.

Call me crazy but there have been numerous times using '07 where it would
pause and for sure in any other version it would have bombed but I'll be
damned if it didn't come back. It's so noticeable it's scary. Again, it
has still crashed but maybe they've at least begun to address the issues.
I'm not saying that the developers don't do anything between releases but
certainly in the past stability and performance have taken a backseat to
toolbar buttons and new "features".

Sorry for the diatribe but you're not crazy... memory usage (or misusage)
was and I believe might still be number one on the list.

- Eddy
www.sldinc.com

 

Keep in mind that when you open an application, not all portions of it are
loaded into memory. As you use it, certain libraries of code are constantly
being added to memory as you use the functions that need them. This is why
an applications footprint grows as you open and subsequently close different
types of files and use different functions within the app. Not saying that
there isn't a leak, but possibly another reason.

Ken

 

No doubt Ken, that's the part you expect. The part you don't expect is the
growing and growing and growing until you've hit the invisible ceiling.
I've never had another application do this and we're talking other modelers
as well. SDRC running on NT using their tweaked version of Hummingbird,
Pro/e on NT, Unigraphics on Sun/HP, etc. They share a similar
core/architectural model yet none hit the ceiling like Solidworks. You had
files you couldn't load on some machines but that's a different way of
handling the memory usage problem. In those case you go back, dumb down the
files and try again.

I theorize it's being forced at the architecture level, meaning it's a
problem with the foundation and that's why it isn't fixed yet after all
these years. As systems have grown and memory more available it is probably
looked at as a liveable situation for them. After all, we've all dealt with
it right? Not sure what they could do about it now, if anything. After
this much time, rewrites at the core level are not typically justified.
Again, '07 seems magically better at this, albeit not perfect. So now we
CTD occasionally but it's a little harder to predict when.

- Eddy