Elvas Tower: I hit the 4GB memory limit - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

I hit the 4GB memory limit Rate Topic: -----

#1 User is offline   railguy 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 651
  • Joined: 10-October 10
  • Gender:Male
  • Location:Kansas
  • Simulator:Open Rails
  • Country:

Posted 25 December 2017 - 10:15 AM

For the first time, I hit the 4GB memory limit and crashed OR from that. I was using an experimental route that a friend is working on and shared with me, so I can't post the log file, but here is the basics that I found. I'd like to know if my deductions about how OR operates are correct.

I ran the new activity that I created for this experimental route yesterday. The activity design worked as intended, but I ran into an OR issue that I didn’t think would happen—it went over its 4GB memory limit and crashed. I ran it again and monitored performance. The activity starts out at the west end of the route with the player train waiting for 6 eastbound trains to pass, then the player train runs to the east end (a little over 100 miles). The challenge is that starting at the west end loads a massive 2.5 gigs into OR before the traffic trains even load. Each traffic train adds more load to the mix—at train #4, OR goes over its 4GB limit and crashes. Reloading the activity from a save made just before it crashes loads only about 2.8GB, and the rest of the activity will then run from that point. The activity does have a considerable number of loose consists, but they are fairly well-spaced along the route.

Here are some strange things that I noticed:
1. Once a traffic train is loaded into memory, it appears that it will stay loaded until it runs its full path, then disappears. However, if one saves, then reloads from the save, a traffic train at some distance from the player train apparently won’t load and take up memory. Strange.

2. I originally thought that certain scenery objects were slowing the frame rates. This still may be somewhat of the case, but I’m coming to the conclusion that the frame rates slow when the OR memory is approaching full and the camera is rotated when that condition in present—probably because the computer is having to dig through so much memory to find the objects to render. I’m not sure what would cure that issue—faster video card, more video card RAM, faster computer RAM, or faster processor. Any ideas there? I run 16GB RAM with a 7700 1GB video card and hybrid hard drive.

3. On my computer, sound rendering was not an issue and did not bog things down, despite OR throwing up numerous error messages in its log about missing .wav files in .sms calls (very common issue with most of the sound files out there).

4. As one would expect, terrain and scenery objects load when the player train approaches them and will unload from memory after the player train is some distance from them. What I did notice is that the “unload distance” is considerable.

I’m going to experiment by shortening up the traffic train paths, so that the first trains have run their path and unloaded from memory before the later ones load to see if that helps the crash problem. That might stop the AI trains from overloading the OR memory, but that doesn't cure problems when the system has to load a lot of scenery objects at one location.

Unfortunately, OR is likely going to have be able to go beyond the 4GB limit that XNA demands if the sim is going to be able to run complex activities over scenery-intensive routes. That is a major project from what I read here at Elvas about it. For what it’s worth, MSTS would have crashed with my activity before it could have even loaded. Also, though experimental, the route I used for this activity is a well-built route, modified by a very talented route "modifier." It is, however, scenery-intensive, especially around the terminal at each end of the route and at one in the middle of the route.

Any thoughts?

PS--Merry Christmas to everyone!

#2 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 25 December 2017 - 10:58 AM

Short answer: use the OR Monogame version and you will solve your problem: you won't have the 4GB limit and that version intrinsically uses less RAM memory.
Longer answer:
Have you checked the "Load day and night textures only when needed" option?
What viewing distance have you selected?
When a train is at a distance from the camera higher than the viewing distance, only the first locomotive shape and texture is held in memory, so minimizing RAM used.
Also scenery loads/unloads at a distance depending from the viewing distance.

#3 User is offline   railguy 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 651
  • Joined: 10-October 10
  • Gender:Male
  • Location:Kansas
  • Simulator:Open Rails
  • Country:

Posted 25 December 2017 - 11:49 AM

Thank you, Carlo.

Answers to your questions:

"Load day and night textures only when needed" option is checked.

Viewing distance is 5,000 meters.

Distant mountains is checked, 70 km distance (I run a lot of mountain routes where distant mountains can be seen for some distance. The route that is giving me trouble does not have distant mountains, however).

I would like to try OR monogame, but have been a little reluctant to try it, since I always use the latest experimental version of OR. Is monogame possible with the latest builds?

#4 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 25 December 2017 - 12:28 PM

railguy,
I'd suggest you to reduce the viewing distance to e.g. 3000 m. That should significantly reduce GB of RAM needed.
Re Monogame, I just made available a version corresponding to the present OR experimental version (x.4018). It's however true that I update the MG version with a lower frequency than the appearance of new OR experimental versions.

#5 User is offline   Eldorado.Railroad 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 977
  • Joined: 31-May 10
  • Gender:Male
  • Country:

Posted 25 December 2017 - 02:30 PM

Firstly, Merry Christmas to you!

1) What took you so long to hit the 4GB limit!? Welcome to the club!

2) I will try to explain this in a simple fashion:

Scenario A:
Say you have a route that YOUR train travels on from A to Z. On that same route, you have AI trains traveling from Z to A. Open Rails will do what you want it to do. As you move from A to Z, objects that are no longer in sight will be freed from memory. In my experiments the only limiting factor you will meet will be a signaling one. That is to say, you can have many AI trains, all unique in terms of shapes etc and you will not encounter a memory error, within reason of course. I make no guaranties with a single AI train using up 3 GBs of memory!

Scenario B:
Now, this is where your problem comes up. Open Rails will fail miserably and in very short order if you do the following:
Your train travels from A to Z, BUT you decide to stop a tile M. At tile M, you wait for a whole bunch of AI trains to pass, going from Z to A. All those AI trains suck up memory and WILL NEVER BE RELEASED, even if you they have moved out of view and have arrived at tile A.

It took a very long time for Scenario A to be addressed/acknowledged by the development team even after I reported it. When it was addressed and squashed it seemed to be a secret fix, because I discovered it was fixed by accident by running a scenario that I had created some years before that now worked without crashing.

Scenario B has not been addressed and has been hidden from view because 4 GB seemed so far away. But you have discovered as I have, that it is not impossible to reach!

I suggest that either you give up on Scenario B or severely cut back on the AI trains. What you can do is make sure you are VERY economical with your AI trains, which is to say..use EXACTLY the same shapes in any consist while you are sitting on a given tile. This of course is boring as heck, but it is all you can do.

If I were you I would file a bug report on this. Maybe somebody will address this very old memory management bug.

Cheers,
Steve

#6 User is offline   railguy 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 651
  • Joined: 10-October 10
  • Gender:Male
  • Location:Kansas
  • Simulator:Open Rails
  • Country:

Posted 25 December 2017 - 04:15 PM

Yep, it's Scenario B. I haven't tried it yet, but I think that those AI trains will quit sucking up memory once they reach their destination and disappear. So, for example, in theory, if AI train 1 disappears before AI Train 3 is spawned, it may not create as large of a memory issue. But, I haven't tested this as of yet. I agree that this likely a memory management bug that should be addressed. If one thinks about it, in real railroading, where is the most congested point on a railroad? Often it is a yard at a major terminal. So, if one is emulating that, you have all the ingredients for a memory crash--scenery intensive area, lots of loose consists, player train sitting for some time, AI trains meeting or overtaking the player train, etc.

I did try OR monogame and it appears to take much less memory, but I am getting some sporadic flashing in the video that I don't know how to cure.

#7 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 26 December 2017 - 02:01 AM

I've checked it, and it is exactly as Steve says (I couldn't believe it) (by the way what I said before, that is that the first locomotive is not unloaded is valid only for the player train). If your camera remains within a tile, passing AI train textures and shapes aren't unloaded when the AI train is farther than 1.5 times viewing distance (it's the threshold used) EVEN if the AI train disappears at its end of run. For the AI train textures and shapes to be unloaded the camera must change tile.
This is undesirable, but finding an efficient solution is not straightforward.

#8 User is offline   railguy 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 651
  • Joined: 10-October 10
  • Gender:Male
  • Location:Kansas
  • Simulator:Open Rails
  • Country:

Posted 26 December 2017 - 08:24 AM

Monogame appears to have freed up enough memory to make my activity work as I designed it. However, as noted above, I do get some flickering and flashing of certain textures sporadically (that aren't present in "regular" OR) and, when frame rates go low, I get stuttering that doesn't show up in OR. By the way, I don't really know what to do with the .patch file that was in the same post as Carlo's latest monogame build. I did some reading on patch files in general, but I don't think that I have any of programs loaded that appear to be needed to run it and update code.

I was amazed how much less memory Monogame takes compared to regualar OR . . .

Thanks for all the work that folks are doing on Monogame.

#9 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 05 January 2018 - 01:10 PM

View Postrailguy, on 26 December 2017 - 08:24 AM, said:

I was amazed how much less memory Monogame takes compared to regualar OR . . .

If you run the XNA version of Open Rails and look at the DEBUG page of the HUD, there's an indication of how much difference Monogame will make:

Quote

Memory 234 MB (..., 48 MB managed, ...)

This line is saying that although we know Open Rails using 234 MB in total (by one particular measure - be careful comparing with other measures), we also know that only 48 MB of that is the Open Rails code and data (approximately). The remaining approximately 186 MB is from various system-level components, such as DirectX and OpenAL.

If you compare the XNA and Monogame versions, this remaining memory will be significantly different because of just one thing AFAICT: DirectX 10+ does not need to keep copies of your textures/models/etc. in the program's memory like DirectX 9 does. And that's a lot of stuff to not have extra copies of. :)

#10 User is offline   edwardk 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,350
  • Joined: 11-December 09
  • Gender:Male
  • Location:Chula Vista, CA
  • Simulator:MSTS
  • Country:

Posted 05 January 2018 - 03:36 PM

Where do we stand on getting all of the monogame bugs wrapped up? I realize Carlo reached his limit working with the code. If we can tie up the known issues and keep it updated, maybe the monogame version can be used over what is used now.

Edit: I found my answer in another post so please disregard this post.

Edward K.

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users