PWx-2 memory issue

Ed,

I have not run a PW2 render beyond 1gig, yet.

What I do not understand is how you can allocate 6 gigs of memory when I thought the max any app can access from windows was 3 gigs (and that is will the M$ switch)? (btw, if you do not have the 3 gig switch, I think the max a app could allocate was about 1.7gigs?)

One thing I noticed with PW2 is it wants to access the net, that is, when I have my firewall up it wants to talk to the network. If you have a firewall, and if it disallows it access, PW2 and SW maybe shutting down because of the access it's requesting?

Otherwise, in the past the crashes I have had with PW2 were with some image maps and decals which I later removed, re-saved as 32bit BMP's and reentered them into PW2.

As for the 35X value for the raytracing, why such a large value? Is it really needed?

Lastly, something I'm sure you have noted, if you change the angle of the scene slightly, it changes the render times for indirect illumination quite a bit sometimes. I'm thinking way out there but maybe because of the angle of that scene, the rays are bouncing in such a way which maybe causing the crash?

(man, I was using SW2004 and PW2 today for a client and I can not believe the wierd behaviors with the gui and sometimes it just crawls at a snails pace!,.. not production ready for my use.)

..

Have you enabled the MS 3 Gig switch? Note: the application (PhotoWorks) must support the 3 Gig switch. I do no know if PWX supports it. The 3GB switch allows a process to access up to 3GB instead of the normal 2GB.

Without the 3 Gig switch enabled, the most memory any single process in Windows can allocate is 2GB. This includes physical and virtual memory. Note: your 1.7GB limit is pretty close to the 2GB hardwired limit. Perhaps you are actually hitting this 2GB limitation.

Background: For any 32 bit OS (including Windows), the maximum amount of memory that can be addressed at one time is 4GB (2^32). The Windows OS always reserves half of all available memory for itself. This means that if you have the maximum of 4GB of memory available, 2GB is automatically reserved for Windows and the rest (2GB) is available to any single process. The 3GB switch changes this relationship, reserving only 1GB for the OS and 3GB for other processes (this is the default in Linux).

Here is where it gets a bit fuzzy for me: You can have more than 4GB of memory (combined physical and virtual), but each process must stay within its 2GB (or 3GB) limit.

Hi Ed,

We ran into this 1.7GB limit using W2KPro OS when SW2003 was introduced. SW in Mass. sent our assy's over to England where they were able to open them on a server platform allowing the full 3GB of RAM to be used. I have been told that WXP Pro has eliminated this restriction but have not checked it out personally. The MS3 switch might be the fix. Do any group members know if this should be applied to WXP Pro or is it part of SP1?

Regards,

Dennis Deacon

Edward T Eat>

Possible work-around...

Export your part/assy via parasolid and bring it back in. Should shrink file size considerably, leaving extra memory for the rendering? Of course you lose all of the PW materials that you have set up so far so maybe not feasible for your situation...

Todd

consistently

Thanks to all who responded. I have blown a good half a day on this, but boy have I learned a lot.

First, I need to ask if one of you could confirm that I have entered the text correctly to enable the 3 gig switch, because the Microsoft web page is miserable - it took forever to find the exact right phrase to search for the switch information, and even then there is no explicit direction (that I could find anywhere) on how to really enable it. Even SWs advice on this subject, buried on page 7-12 of the 2004 whats new manual, points to wonderfully imprecise pages at microsft.com that do not give exact, clear instruction. Why can't they just say - to turn on the3 GB switch, type [this]????).

Anyway, when I edited the boot.ini file, I typed the line '/3GB' between the lines '[boot loader]' and '[operating systems]' lines. Is that how I turn on the switch?

Now the bad news. If I did this correctly, it doesn't make a damn bit of difference to preventing crashing. Actually, thats not entirely true - I am now crashing at 1.6GB of memory usage instead of 1.67, but I think that's splitting hairs. I do not see evidence that PWx can utilize the memory freed up with the 3GB switch.

What does help is to LIMIT the 'maximum memory allocation' in PWx. I always assumed that we should INCREASE the value in order to prevent PWx from crashing - after all, the crashes say that PWx ran out of memory, so more memory is better, right? But hey, why should intuition enter into this. If I look at the memory usage before I start rendering (1.2 GB for this assembly), then subtract that from my crash point of 1.6 Gig, I have 400 Meg left for PWx. If I set my maximum memory allocation to 350 (I want 50 Meg of slop just in case), PWx builds up to 1.55 of memory use then releases a little to go back below that set value. No crashes. I think I'm pretty close to the right idea, because if I increase the allocation to 450, I crash almost immediately. Thanks to the guys at CATI tech support for pointing towards this novel approach.

In summary: I think the best practice going forward will be as follows: Set the ray trace depth to a middling value - 35 seems to work well and not crash every time (note for Paul Salvador - a higher ray trace depth is supposed to cache more info and speed up rendering time). On smaller assemblies or single parts, I will jack this all the way up. Then I will use the 'maximum memory allocation' as a safety net, in case the cache gets too large. This ought to be set per assembly, based on the static memory load of the assembly in SW.

I am also going to have a little conversation with the folks at SW, because this whole thing could have been avoided if they just limited the 'maximum memory setting' so it couldn't be higer than 1.7GB - which appears to be PWx limit, not even counting the usage of SWx which would nibble 100 Meg off of that value. We wouldn't have blown a wad on more memory, and I wouldn't have blown a morning experimenting with this crap, if they hadn't dangled the (apprently) erroneous notion that PWx can use up to 10 gig of physical and virtual memory to speed up rendering..

The application must support the 3 gig switch. I remember a statement that SWX2004 now supported this memory option, but that does not necessarily mean PWX also supports it.

Note: I have never used or needed to use the 3 gig switch, yet, but I am getting close!

Ed,

Thanks for sharing this, I'm sure it was painful though.

Interesting about the high raytrace value, kewl!

What Arlin said makes sense, PW2 is a seperate app and it may not be able to use the /3gb and with SW already demanding most of your memory PW2 may also be sharing similar memory allocations = they don't play well at that boundary?

BTW,.. I think your /3GB switch is correct?

..

I ran into this exact problem a few months ago and could never solve it. I figured they would fix it in 2004. I'm sorry to hear it's still not resolved. Thanks for keeping us posted Ed.

Mike

Paul, thanks for the link. I don't know how many f*(&($^ing articles I looked through trying to find the simple example text that you provided in the link below.

Of course, the problem is that my boot.ini file does not look like the one they show. Mine has this '/fastdetect' element in it that I assume exists for a reason.

Here's my boot.ini file: [boot loader] timeout=30 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

Since we had nothing better to go on this morning, we originally tried: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS /3GB [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

Nothing seemed to happen either way after this change. PWx still crashed, but everything else seemed normal.

Then, Paul's link pointed us in the right direction. But since I was loathe to delete that 'fastdetect' thing that must be in there for a reason, we thought we'd give this a try: [boot loader] timeout=30 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

Ummm, for the record, don't do that. Windows will not reboot ever again, you can't get in to fix the file, and the machine dies.

Fortunately, we recovered by booting off of a copy of my operating system on a spare drive, fixed the boot.ini file back to what it was originally, and are ready for another round.

So, unless I hear otherwise, I will delete the '/fastdetect' bit and replace it with '/3GB'. What the hell. Tonight, I make a backup of my C: drive just in case this screws up everything. And I am quite curious why there is '/fastdetect' in the file in the first place, though - any ideas?

This computer stuff is fun!

Ed

Page 7-12 of the what's new in 2004 manual says SW supports the 3 gig switch. I have some feelers out about whether PWx enables it, and I'll let y'all know if word comes through either way.

Begin editorial comment: I wish they didnt call this the /3GB switch. A switch is a simple thing - you flip it, and something goes on. This feels more like the /3GB hack, where you have to take a delicate system file and, with very little information, figure out the correct code and syntax to successfully hack your system. 'Switch' my ass. End editorial comment.

Ed,

I'd be very careful about putting a switch that close to my ass. The first definition in my dictionary for switch is "A slender flexible rod, stick, or twig, especially one used for whipping".

Jerry Steiger Tripod Data Systems

Ed,

I think you can get rid of the /fastdetect switch (speeds up loading) and/or add /3GB before it?

But yeah, you can make a 3.5" boot disk if this happens and use the old dos edit program to change it back. But always make a backup copy of the boot.ini.

..

LOL!

ROTFLMAO!! Hey, I thought that was a willow tree branch?

..

***Disclaimer-if you are sensitive about the exposure of faults in SolidWorks software it is advised that you refrain from reading this post. Reading this post may cause the following: you might cry if you make a living off this software, get mad, agree with me, or in extreme cases contemplate demoing Inventurds, Pro/Enema, Unigiggles, Solid Idiot or even Cad Star 5D(still in Beta). Could even cause babbling about seamless, unified, hybrid modeling and cause paranoia that the CAD monkeys are brainwashing everyone into thinking they can get the job done via the 'hack and whack' methodology and are constantly following you with 'white papers'. The following information is not propaganda and is intended to share real world frustrations with SolidWorks software. If you are employed by SolidWorks, by reading this post you are hereby agreeing to publicly recognize the issues with your software and make a public apology, service pack and free subscription available within 30 days.***

All,

This is definately not contained to PW2 itself. This is a core issue in SolidWorks and has always been there. They hurried up and wrote some code so we could open up a 7,500+ part assembly 2 years ago. In other words 'hurried up and put on a band aid' so we would buy 10 seats. SolidWorks is definately aware of the problem, but I guess they a)don't really care or b)don't have a company with 200 seats threatening to move to a different CAD program unless it is fixed. SolidWorks Corp. has had my large assembly models for a year now and the only response I got from them was 'hey we can open them'. Wow, open them. Now thats really all we do out here in the real world. I wouldn't be so bitter if they didn't advertise large (10,000+ part) assembly performance.

We experienced the same problems in SW2003 and SW2004. Unfortunately, the /3GB switch also does not work in OS's other than XP and 2003 server. I was on Win2000. What kills me is they brag about 'unsurpassed large assembly functionality' and 'we have a user with a 100,000+ part assembly.' Blah-Blah-Blah. I dealt with the crap for 2 years and fortunately for me I now work at a company that does small assemblies. I'm also proud to say that I had to take screen shots of an assembly and paste them into a drawing because SolidWorks(sometimes) would die otherwise. Maybe thats what they guy with the 100,000+ part assembly is doing. Try cropping a large assembly view and see what happens Mr. large assembly guy.

The out-of-resource issues for will show up for everyone around 1.6-1.7GB. My personal opinion-ain't gonna get fixed anytime soon. I mean they have people like Ed Eaton running all over the MS knowledge base all day just trying to figure out how he can hack his boot.ini file. And Ed , c'mon, you know SolidWorks wouldn't explain how to do it in any of their documentation. That would mean that if you followed the documentation and it didn't work they'd be at fault. They've been poiting the finger at MS since I brought the issue up.

Funny - we did the dos boot disk thing, but could not get back to the C: drive to resurrect things. It was stuck on A: Just a warning to those of you who want to try this at home. Scary stuff.

"Edward T Eaton" wrote in news:bn60eu$tfqp4$ snipped-for-privacy@ID-139356.news.uni-berlin.de:

A DOS system disk won't be able to read the boot drive if the boot drive is formatted NTFS. For that trick, you'll probably want to be formatted with FAT32.

Thanks Dale - I'll make a note of that. So your saying that my boot drive has to be FAT32, right? We have another way that is pretty darn safe, and won't require me to reformat anything. We have removeable hard drives, and I just copy my C: drive to the removeable before making big changes (nice to have a really huge safety net). When everything goes to hell, we can boot off of the copy and, once booted, we can fix just about anything. Its nice to have the copy in my desk drawer for other reasons - if the boot drive goes bad, we get hit by a virus, or any of the other digital plagues nail us, we can plug in the backup and keep working with barely a hiccough.

Just for the record: I changed the boot.ini file to match the text on the Microsoft page that Paul linked us to.

timeout=30 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

That killed my system again. End of this phase of the experiment. I'm starting a new thread, and we cn maybe continue the fun there.

Thanks to everyone who pitched in!