FSX still need /userva switch even on x64 OS's?

[Guest Nick_N]

>We really need to get this 64 bit (program) show on the road. I agreeIts time to make that shift and if Aces/MSFS wishes to be 'cutting edge' I think its time a 64bit build be considered and developedBut that is another subject

[Guest Nick_N]

Understood but your situation is not the norm and now that your new system works fine with the switch, that is of course up to you if you want that line and pause in boot.You also fully understand what it does and can recognize a problem should you be using one script or another.I did not say it would not work or that it was not wise to do.. what I was saying is it adds more options to a system than it needs too if the system never displayed a problem with the switch, and, especially with users who are not tech savvy. If there is a defined need for it then there is a reason to add it.I dont believe in making things more complicated and adding in elements that have the potential to create other issues, especially when most who may try something like that are not in tune with what they are doing.I much prefer the trimmed down approach and only use additions that if required.It is a good option and if one is willing to deal with it correctly, it does work. ;-)

[Guest Nick_N]

>but I have a TON of processesOK, this is where I was talking about cleaning up that startup system and the one area I do not post a "how to' for.If you know what you are doing or get the proper assistance, with XP you should have no problem trimming the running processes at boot down to 35 or less, probably 30 or less like I run. If you are running more than 40 that is probably where your performance is going even if you followed all of my instructions correctly.As for the video issue it sounds like either some type of addon (outside of FSX) like fraps or other, or, some kind of BIOS/register problem with newer drivers

[tf51d 284]

I agree, once you know it will work on your system, you can just add the switch to the primary boot string, but since I have a multi boot system anyway, between Vista and XP, I just left it that way!

[Guest JIMJAM]

I can use Enditall and chop most of them off but I see no difference.Most use very little anyways but some are tied into the Creative labs card,Nvidia services,Logitech and for some reason I have 14 svchost.exe entries.Most are NETWORKSERVICE,LOCAL SERVICE or SYSTEM.Ive turned off all the usuals,Restore point,Indexing,anti-virus ect ect.When you read a gamers guide to XP performance simular to yours, Ive tried them all.The problem is, even with a pristine OS and JUST FSX, you have to add a mouse,a joystick,a sound card. You want real player,windows media player, NEED to go online ect ect.So with just the essentials you never REALLY have a clean slate.Any of these things cound possibly cause and do create conflicts.When you start forcing them off or keeping them from starting, eventually you will need them and problems begin.I bought my first console,a PS3 2 months ago and have completed 8 games. Not ONE crashed or failed to load on me.The fact that I was not able to tinker with the hardware and code might be a good explanation:-bla I tell ya . It helps to have a sense of humor,and good credit, to enjoy this fine hobby of ours.

[Mike T 208]

Fair enough Phil and a very educational edification to be sure. So then my question still remains, and I am sure I am missing something along the way.My system: Vista 32-Bit Ultimate /3GB switch is already enabled with 4GB total memory.1) Background Non-Windows Native Apps. Skype, ATI CCC, HP Display Manager, Lightscribe, HP Digital Image Monitor, Saitek Pro Rudder Pedal app, Saitek Pro Yoke/Thottle App, Kaspersky Internet Security 7.0.x, Creative Labs X-Fi Control PanelTotal Memory Used Including Vista native services and processes ~ 1159MB.2) Run FSX SP2 without disabling ANY services outlined in item 1, Ground Environment X textures, Flight Enviornment X textures, ASX, Settings High, Flight1 Cessna 172-R, DreamScenery Ohare in background, my work-in-progress (soon to be released - KPWK - Chicago Executive Airport) sceneryTotal Memory Used including everyting in section 1 ~ 2235GB. Does not fluctuate more than a few hunderd meg and no less than 800MB of application memory free at any time.Okay so that means that my pretty dooded up version of FSX is taking about 1.1GB of application memory.If I then switched to Vista-64 and added a few more Gig of RAM would FSX use it if it is not using it now; because it is not needed because it is not even using the 3GB total that it has now?So that is where my scepticism lies of the Vista 64-bit, uberRAM machines. IF FSX runs on the average 32-bit OS with 4GB of RAM, what is the benefit of raising that? AND, if you cannot get FSX to run within the confines of a 32-bit 4GB system, do you see that as an indication that there is something wrong with FSX or with an addon or system configuration setting?The hump I'm having trouble with is that if 90% of FSX users can run the app with no need for background service disablers, 64-bit OS's, or /LARGEMEMORY switches what does that signify? (or not?). Likewise if you pile 8GB into a 64-bit OS and FSX is taking 4GB of that when I see it only addressing less than 2GB, what does that signify and what would be the recommendation?Regards,Mike T.

[Guest Nick_N]

The game sites are dangerous and you do not shut things down and 'end process' after Windows is booted.Remember, I said the right items need to be correctly removed and that part of the system addressed and then a reboot so the footprint is not on the system, at all. You do not need to shut things down for "gaming' and those 'special lists' of services to shut down are complete BS, dont use them.Those websites, like black viper, post information that is dangerous and they do not tell you how to shut down services correctly either. Many of the services they list to shut down can CAUSE problems and issues.You need someone who knows what they are doing to go through it and do it right. If done correctly what you end up with is what you use all the time when you boot. there are NO SPECIAL boot profiles involved.The diagnostic install as I posted should eliminate other apps, including AV, etc. The idea is to test with only the OS, drivers, updates, Nhancer and FSX installed without addons and without winamp, winzip, WMP11, Office software, etc and all that other junk. Its a clean install to eliminate as many variables as possible and go from there.if you still see the issues you posted then there is something out of sorts with the hardware

[Guest JIMJAM]

I am just going to accept that this is the hand I was delt and just DEAL with it until I rebuild. I take confort in knowing there are ALOT of people with even worse problems that have much more current and powerful machines than mine. My freind has talked me out of "upgrading" for some time.He blames the crappy programming. Not just FSX mind you but the overall state of hardware/software turmoil where everyone is on a different page. I really do not care anymore about blazing fps and eyecandy but good ol stability.I will once again Thank you and let them get back to the original topic.I am a real world pilot and if you are ever down south look me up and we will do some heli/plane flying. Jim

[PhilTaylor 45]

>>Total Memory Used Including Vista native services and>processes ~ 1159MB.>>2) Run FSX SP2 without disabling ANY services outlined in item>1, Ground Environment X textures, Flight Enviornment X>textures, ASX, Settings High, Flight1 Cessna 172-R,>DreamScenery Ohare in background, my work-in-progress (soon to>be released - KPWK - Chicago Executive Airport) scenery>>Total Memory Used including everyting in section 1 ~ 2235GB. >Does not fluctuate more than a few hunderd meg and no less>than 800MB of application memory free at any time.>>Okay so that means that my pretty dooded up version of FSX is>taking about 1.1GB of application memory.some of that 1.1G from the OS is shared DLL space and ends up mapped into each processes address space.so when TaskMon states "process mem used" I do not believe it is fair to subtract the entire base OS value from the process value. can some of the base be subtracted? Maybe.We'd have to look at a Win32 SDK HeapWalker memory map to understand this for sure. The tool downloadable fromhttp://www.codeproject.com/KB/winsdk/system_scaner.aspxalso looks interesting.If you turn off the /3G switch, do you crash? That would indicate the 2.2G in the process is really past the 2G line. What if you load a complex aircraft? And turn all sliders to max?>>If I then switched to Vista-64 and added a few more Gig of RAM>would FSX use it if it is not using it now; because it is not>needed because it is not even using the 3GB total that it has>now?process address space and physical RAM usage are separate.having more physical RAM does mean the OS can satisfy RAM allocation requests with physical instead of virtual pages. this can be a performance benefit. so there is some benefit from having more physical RAM.FSX-SP2 will, when the /3G switch is set, get allocations from above the 2G line from the OS. The OS itself is what stops this when the /3G switch is not set. How exactly those are mapped to physical ( as compared to virtual ) RAM pages is completely under the OS control. With more physical RAM, the odds on getting a physical page when asking for more memory are greater but that still isnt a guarantee.>>So that is where my scepticism lies of the Vista 64-bit,>uberRAM machines. IF FSX runs on the average 32-bit OS with>4GB of RAM, what is the benefit of raising that? AND, if you>cannot get FSX to run within the confines of a 32-bit 4GB>system, do you see that as an indication that there is>something wrong with FSX or with an addon or system>configuration setting?Win-64 just grants more process address space to each Win32 process. 3G is the max on Win32 ( with the /3G switch) and 4G is the max on Win64.How physical RAM pages are then mapped to process pages is another issue entirely.>>The hump I'm having trouble with is that if 90% of FSX users>can run the app with no need for background service disablers,>64-bit OS's, or /LARGEMEMORY switches what does that signify?>(or not?). Likewise if you pile 8GB into a 64-bit OS and FSX>is taking 4GB of that when I see it only addressing less than>2GB, what does that signify and what would be the>recommendation?we need to separate physical RAM from process address space, thats what this signifies.when FSX ( before SP2 ) hits an OOM condition it typically means 1 of 2 things:1)no free block of the right contiguous size was available2)the size of this allocation would place the app outside of the 2G process address space limit.adding support for the /3G switch helps with both of those conditions since there is both more room for contiguous blocks and more process space to fit in.>>Regards,>>Mike T.

[Guest D17S]

These trials really remind me of the days when I was trying to get LOMAC to run a 6600GT (in the days of the 6800GT big dog) on a P4 at 3.2. Crash, frag , lockUP . . . and a generally (and endless) Battle Royal. The guys with 6800GTs and a AMD Athons at 2.8 fought for frames, but at least LOMAC ran without erratic nonsense. The program was simply too much for my system at the settings I wanted. Lately with a Q6 @ 3.6/8800GT/4Gram I reinstalled LOMAC. It's running like a dream with nothing more than the install button click. >> If I then switched to Vista-64 and added a few more Gig of RAM would FSX use it if it is not using it now; because it is not needed because it is not even using the 3GB total that it has now?Again, this seems to misunderstand the V-memory concept. Think about it as a forecasting tool. The program tells the op system how much memory it is - forecasting - it will need. It adds in the Vcard memory too. The actual physical ram load or the amount of ram physically installed NOT considered. When the op system sees that the program is - forecasting - a memory requirement of over 2Gs (3Gs with a 32 bit system 3g switch, or 4Gs with a 64bit op system running a32bit program) it abruptly and without ceremony shuts down the program. You are NoT OOM. The op system's ram forecast 'tally-sheet' just went over this magic number. Remember the Vcard's memory requirement is added too. Once these 1G Vram'd GTX280s get out there, the wheels are gonna come off these 32 bit rigs. I often see 3G+ physical ram loads with FSX on my 4G-ram'd, 64bit op system. FSX may only be using 1.3G or so, but I like other stuff at quick hand. Now consider: With a 32 bit system, I could still use 3G+ of physical ram even without the 3G switch set. This is because physical memory usage and the Vmemory's 'tally-sheet' do NoT interact. Each and every program has a - Separate - 2G (or 3G) Vmemory 'tally sheet.' If I had 10 programs running, I could have 10 x 3 = 30Gs of ram "Allocated" via this Vmemory system. My physical ram load could be anything . . . up to the 32bit systems ability to use - Physical - ram. Again (for this lay and analogous discussion), this is because physical memory usage and the Vmemory's 'tally-sheet' do NoT interact.I like the 64 bit system because I can use my Full 4Gs of Physical ram. I can burn up 3+Gs of ram for program quick access And Still Have Room for the op system to continue to operate normally. If I was using 3Gs+ for programs with 32 bit system, the op system would be crowded: Hard. This Vmemory thing will still be working in the background, but it is unrelated to physical ram usage. Remember each program had a separate 2-3-4G tally sheet limit before it shuts down. The amount of this Vram being 'tally-sheet tracked' can be MaSSive. I never had OOMs, ever. But the 64bit system gets me a bit more 'tally sheet' headroom before the program just crashes. This Bigaddressaware (whatever) switch Only ups a 32 bit system's (3gig switch enabled) 3G limit to 4Gs on the 64 bit op system. -- If this tally-sheet number gets to 4Gs on a 64bit system, I expect it will shut down just like a 32 bit-er does at 2-3Gs. -- I also expect the 64 bit system does not have a pop-up OOM message. After all, the 64 bit op system's 64bit program (process) tally sheet limit is Eight Terabites - each - ! The (old-school) PhDs of the 60s thought 2 gigs was a ridiculous number that would never be reached by any single program, but here we are. These guys taught a new generation that now presumes 8 Terabite is a a ridiculous number that Will never be reached. We'll see 'bout that, but I expect the 64 bit system (self-rightfully) does not even have an OOM popup. We may be seeing the 1st 64 bit OOM here. . . at 4Gs. It's time for 64 bit programs. 2G Vcards can't be far behind this (soon to be mainstream) GTX280. I see a 32bit train wreck a commin'.

[Guest Nick_N]

>We'd have to look at a Win32 SDK HeapWalker memory map to understand this for sure. >The tool downloadable fromhttp://www.codeproject.com/KB/winsdk/system_scaner.aspx>also looks interesting.Thanks for that one Phil! :-beerchug Will check out that tool ASAPalso:http://www.codeguru.com/cpp/w-p/win32/tuto...icle.php/c9495/

[jordanal 70]

God, I must be a geek; reading threads like this give me goose bumps, LOL! Thank you all for your input and a very interesting conversation.I consider this topic a twist to the previous OOM discusions because of the 64-bit OS involved. I hope to re-run the same lenghy PMDG 744X simulation this weekend. I have now confirmed that I do have the Swap hard-set to 3072MB and will as Nick suggests in his opening post, change it to system managed and see if that makes a difference. I can tell you, the two most recent changes to my NickN-integrated FSX server is the addition of FEX running 1024/dxt5 clouds and water and the latest service pack to the PMDG 744X ram-sucking monster that we all know and love. I found the theory of the 64-bit OS not producing an actual OOM error box statement above interesting because I do not get one. But, as mentioned in my OP post, the very sudden crash to desktop and the fact that it was a different .dll reported as the error, is very very reminescent of the OOM events I fought in FS9. I personally spent the better part of 6 continous months building and rebuilding, and testing again, until I was absolutely sure it was not my rig or integration, and determined that it was the collection or combination of all add-ons producing the CTD. And, the worst part is, it always took the PMDG 744 and high-end scenery to do it; and it was always after a lengthy flight, usually about 20nm from the landing and was very painful to test a long flight, just to usually wind up with a CTD, just before landing.My gut feeling at the moment, until I retest with swap change to system managed, is that with the high end add-ons, 7cm textures, dense autogen, lots of AI AL, 1024bit clouds, the PMDG 744X, simconnect, FSUIPC, ASX and everything else, we are approaching the same kind of issue. God, I hope not![Edit:] I should note, changing the swap on my WinXP-x64 rig (4GB RAM) from 3072MB to system-managed did change the initial swap allocation to 4106MB.

[Mike T 208]

As usual a wonderfully technical explaination (I eat that stuff up). So I understand the memory address space differences, so in the case where I've never seeing a spike over, for argument's sake, 1.5mb of FSX usage irrespective of the complexity of the addon's I pile upon poor FSX. Note: I don't equate performace with memory usage in the case where I know that I have plenty of physical memory (so far) but complex addon's will cause less performace as is expected.But what I think I understand from your explaination points to sharp differences on a system-by-system basis. Apropos, all of the things I've got running in the background on Vista Ultimate + FSX + the most advanced addons (I've been on a FSX buying spree lately) don't cause me a memory usage issue, with no switches or 64-bit OS requirement. In the same token, the minority who need to switch over to 64-bit, etc may have other differenciating factors that are totally out of your control but still it fixes their OOM issues.I still like to think that one should first look at their existing system, addons and configs for the initial source of the OOM. But in the same token, heck, if freeing Windows to access more memory is the fix, it is a path to the same end, a flying without OOM errors!The value of your posts cannot be overstated...good to see ya at least keeping us on the straight path of technical rightousness! :-beerchugBest regards,Mike T.

[Guest D17S]

Well, if any super geek wants to actually watch this train wreck in action, here's the tool: http://technet.microsoft.com/en-us/sysinte...s/bb896653.aspxAnand has been Way out in front of this. We are not the only ones getting these OOMs. Look over their 2007 article here: http://www.anandtech.com/gadgets/showdoc.aspx?i=3034&p=4Setup Process Explorer by selecting to observe the columns described in the following excerpt of the Anand article (View > Select columns): "The - WS Private - (Working Set Private) column lists how much physical memory the application is using, and this is the same column listed by the Windows Task Manager for memory usage. The - Private Bytes - column is the total amount of memory the application is using. Last but not least however is the -- Virtual Size -- column, which finally lists the amount of virtual address space allocated, the metric we're after" (Anandtech).Watch "Virtual Size." Also notice EveRy process and program is being tracked independently. They All - individually - can go to this Vram limit. A 32 bit systems will OOM any process/program right on schedule at 2G (w/o) and 3G (w) the switch. My guess is that a 64 bit system will OOM (crash) a 32 bit program at 4G.I played with FSX on a 32 bit install without the switch back in 07. It OOM'd precisely as the Virtual Size number hit 2G. Boy, I had to work at it. I set every slider to the right, then just let the Amazon mission slug along at 2 FPS as I watched VS roll on up. FSX shut down and OOM popped up right at 2G. Right on schedule.Give it a try.

[Guest JIMJAM]

This is always a HOT topic but.....What is the consensus on virtual memory settings?Example- I have 2 gigs,XP.I am using 3048 for initial and maximum.I do not want to start the 1.5x your ram debate just a few ideas.