the 3GB Switch?

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

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

[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

Gil Alsberg wrote:

WT

sorry forgot to poste the links

part one:

part two: Regards

Deepak Gupta

Eng> Dear Gil,

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

"Michael Eckstein" wrote in message news:D1MZg.291$ snipped-for-privacy@newsfe04.lga...

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

"Gil Alsberg" wrote in message news:newscache$1hae7j$pvg$ snipped-for-privacy@news.actcom.co.il...

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.

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