MSTS Cannot Use More Than 2GB of Memory, Or Can It?

[rdamurphy]

As a 32 bit program, MSTS is capped at 2 GB of Memory, and is not capable of using more.

Just like any 32 bit program running on any PC, regardless if 32 bit or 64 Bit CPU/OS.

Everyone knows that. Right?

However. In the regular gaming world, outside of our little realm, there has been experimentation with making 32bit programs "Large Address Aware." This allows a 32 bit executable to use 4 GB of memory on a 64 bit system and 3 GB on a 32 bit system.

Generally, this is possible on any program created after 2000.

So, does this work with MSTS?



Look at the numbers. 2.22 GB of RAM. I couldn't get a screenshot, but I did push it up to 2.81 GB.

So... Yes. Setting the Large Address Aware flag in the Train.exe executable will allow you to use up to 4 GB of RAM in Windows 64 bit OS's and up to 3 GB of RAM in 32 bit OS's. Without the flag set, I never went over 1.87 GB of RAM use.

Of course, you must have more than that much RAM installed, probably 8 GB in a 64 bit system and at least 4 GB in a 32 bit system.

I realize this is going to be quite controversial for some here, and I also realize that it may not work on everyone's computer, so, I'll throw it out there, but if you trash your MSTS without backing it up first... Well, back up first. And remember: YMMV.

Go here to unload the Large Address Aware application, run it in Basic Mode, and flag your Train.exe and try it.

http://www.techpowerup.com/forums/showthread.php?t=112556

The download is at the bottom of the first post, below the pics showing how it works.

Robert

[EricF]

Interesting! I wonder if using the MEM switch enabled by BIN would allow the amount of memory to be fine-tuned -- in other words using this utility to open up larger address space for MSTS (which might be "unlimited" within Windows' memory management) and then set a controllable maximum allocation with the MEM switch and an appropriate value. Have to give it a try one of these weekends...

[Norfolk&Southern 1894]

This will be getting some attention from me when I get home today!

[Claude350]

Rob did you notice any changes in how MSTS ran?

[rdamurphy]

Yes, framerates went up quite a bit...

The mem switch will not enable LAA, and using it, MSTS will only use a maximum of 2G (2048). What effect it might have with the LAA flag enabled is only speculative, but without using it I was pushing awfully close to 3G of memory at one point.

What was interesting is that with the flag enabled, the memory use varied quite a bit, from around 1.6 to about 2.8. Without it, it maxed out at 1.87G and stayed there without changing.

Robert

[eric]

Quite interesting... presumably, since the RE is embedded in Train.exe, we'll see the same benefits there...

I've never paid attention to the memory use when using them, but I'm wondering if it will also help improve performance with Demex and Mosaic.

[mc130fox]

https://www.trainsim.com/vbts/showthread.php?296850-As-requested-MSTS-can-address-over-2GB-of-address-space

[TrainSimulations]

Maybe I misunderstand the data you're presenting, but I assume you get the 2.22 GB number from the Working Set Number on the Resource Monitor? If so, 222020 KB is about 217 MB. We've done a lot of testing on this area with our recent routes, and I can't recall the working set ever exceeding 1 GB physical memory. This isn't to say that it can't, I've just never seen it. Again, this isn't to hinder your efforts, and if the 2.22 GB number is coming from another field in the Resource Monitor, please do correct me.

Regards,
Jason@SLI

[Claude350]

Was there any load stuttering?

[derekmorton]

Memory use has nothing to do with load stuttering.
Load stuttering is a programming issue as they used JIT loading of objects from the disk.

[GoGoran]

What was interesting is that with the flag enabled, the memory use varied quite a bit, from around 1.6 to about 2.8. Without it, it maxed out at 1.87G and stayed there without changing.
Robert

First of all, kudos to you, Robert, for scouting this neat trick out and bringing it to the forum's attention.

Even with mem:2048 set, my unchanged train.exe never used more than 1.45GB of RAM on my machine and every time it went beyond 1.2GB roundabout, it crashed sooner or later (hence I know how much memory it used, since I called up the Task Manager when it crashed and saw the RAM use reported there). My system is Windows Server 2003 R2 32-bit.

I will be sure to check this wonderful new tweak out ... and can't wait to see the boost in framerates !

[derekmorton]

What routes are people using to test with LAA?
Are you quoting memory usage for train.exe?

[qballbandit]

"Memory use has nothing to do with load stuttering.
Load stuttering is a programming issue as they used JIT loading of objects from the disk."

Another interesting sub-topic. I say this because when I use the mem switch at 1024 or 2048, MSTS runs smooth.
Without using any mem switch value, a very noticeable stutter is present throughout.
Never understood why, but on my system, the difference is readily apparent.

[apco25]

Without the "hard allocation" of memory to MSTS you're probably forcing the OS to use that damn paging file and there by inducing some load stuttering at it spins the drive to find the data.

[rdamurphy]

Maybe I misunderstand the data you're presenting, but I assume you get the 2.22 GB number from the Working Set Number on the Resource Monitor? If so, 222020 KB is about 217 MB. We've done a lot of testing on this area with our recent routes, and I can't recall the working set ever exceeding 1 GB physical memory. This isn't to say that it can't, I've just never seen it. Again, this isn't to hinder your efforts, and if the 2.22 GB number is coming from another field in the Resource Monitor, please do correct me.

Regards,
Jason@SLI

Well, Jason, going back and looking at it, it appears that you're right. We're no where near even 1G of memory, are we? Odd.

I tried PRR, which of course, always takes a toll, and the maximum memory usage, using Process Monitor, was 568.43 MB, still much higher than the what I've normally achieved.

In addition, for the first time ever, I ran the PRR for one hour, twenty minutes, without a crash. Although I do need to brush up on my NEC passenger operation skills... Oddly, the evaluation told me I missed 3 station stops, but they weren't listed on the timetable...

Anyway, it is interesting that I never dropped below 59 FPS, something that's never happened before, and the stuttering was very minimal, almost unnoticeable.

Robert