[RESOLVED] OOM reproducible with world wide slew

[Shojom]

1. There is at least one simply reproducible scenario in P3D leading to OOM state
2. This OOM is a builtin malfunction in Prepar3D
3. This OOM is a side effect of limiting the frame rate

Gradient with unlimited frame rate:


Gradient with frame rate limited internally by setting "Target frame rate" to 60:


Gradient with frame rate limited internally by setting "VSync On":


Gradient with frame rate limited externally with "nVidia Inspector:


The tests have been made with minFmaxP configuration (minimal Features maximal Performance). That means: All settings are set to minimum, off or disabled. All addon and stock sceneries (except those not allowed to be disabled) are removed. All other addons are removed (by fresh installation). There's nothing left than core Prepar3D.

Download this file (with Save target as ...) and read with Notepad:
http://virtual-etnh.de/~upload/Shojom/T ... nFmaxP.cfg

This is how the Scenery Library looks like:


The fligth starts a Fury_1500 from Latitude 0 Longitude 0 with heading 360 at altitude 30000 feet:


Flight is in SLEW mode, view is Outside Top-Down with Zoom Out far as possible, speed fast as possible 64000 KIAS:


OOM state is reached within 15 minutes (on my machine).

The test result is independent from
- screen size and resolution
- full screen or windowed mode
- window size
- joystick or keyboard only
- application installed on HDD, SATA-SSD, PCI-SSD or RAM-Disk
- everything else what's installed and/or running on my machine

Test Environment:
- Software
- - Prepare3D 3.4.14.18870
- - nVidia Inspector 1.9.7.3
- - Sysinternals Process Explorer 16.12
- - Windows 7 Ultimate with Service Pack 1 and latest updates
- - nVidia Graphics Driver 375.70
- Hardware
- - CPU I7-5960 not overclocked, running at 3.5 GHz, watercooled
- - GPU nVidia GeForce 980 Ti, watercooled
- - Memory 128 GByte (112 GByte used for RAM-Disk)
- - Motherboard ASRock X99 Extreme11

Thank you Lockheed Martin and thank you Prepar3D team. As a retired teacher for software engineering I know what it means to develop and maintain such a complex application. I hope, my tests and results can help You a little bit.

Shojom

[Martyson]

Shojom,

My frame rate limit was set at 20 (locked) when I installed P3D 3.4.14.18870
I left it at this setting.
I have no reason to change it.

I have i7-6700K
I do not overclock the CPU

Never had a problem with OOM's on this or previous versions of P3D.

[Shojom]

Martyson,

many people do not experience OOM because they fly with normal speeds and not more then couple of minutes or few hours in sceneries with normal much elements. In such case it will take very very long 'till You get Your OOM. That's why I've made the tests above, to provoke the OOM reliably. Moving around the globe with 64000 KIAS loads much more data into memory than with 250 KIAS or so.

But You can check it Yourself. Download

https://technet.microsoft.com/en-us/sys ... ssexplorer

from Microsoft, select Prepar3D with double click, and share Your result.

Shojom

[FSTramp]

I have to confirm the OOM effect in slew mode.
W10, I7-860, R280x, P3D in current version, no addons, moderate settings at 30 frames. Within 10-20 Earth Circuits the memory consumption increases from 1.9 to 4GB. This is a serious program error.

[Afterburner SST]

I can also confirm this behavior.

Limiting the frame rate internally to any value results in a creep-up of VAS over time until an OOM is triggered. When the frame rate is not limited, the VAS goes up but stabilizes at some point.

Out of interest, I have rolled back the client to v3.2 and deleted all related files (AppData, shaders, etc.). The behavior is still the same, although I feel like the VAS was piling up slower. But still, if you wait long enough, you will eventually reach 4GB of VAS and OOM. I have also rolled back the Nvidia GPU driver from 375.73 to 362.00 on my test system out of interest, but it hasn't changed the behavior.

Personally, I don't have any VAS issues with v3.4, but I don't use a frame rate limiter. Maybe that explains it. Limiting the FPS might explain why some users run into VAS problems with this version, so any feedback from them if they run on unlimited FPS or not would be helpful.

[davecessna]

I ran Shojom's test and can confirm that my stock sim does OOM in around the same time.

[Kayla Dillon]

Hello,

Thanks for taking the time to post these instructions. We are able to go through your procedure and will continue testing.

Regards,
Kayla

[Shojom]

Great, Kayla. This your post was what I was hoping for.

[bcrawley57]

A very interesting article, so is the recommendation to set frame rates to unlimited? Also Vsync to off. I have, as with others only recently started to experience OOM's, even with sparse settings and textures at 512 x 512. Before the latest updates I had no OOM's at much higher settings.

[Shojom]

By the way, Kayla, this test shows up two more weak points in Prepar3D:

- There seems to be a problem with spherical geometry when the route hits the poles. Heading changes a few degrees, but we still stay on circumpolar orbit. This means, the problem occurs EXACTLY at north and south pole. Probably this is an effect of limited precision when working with floating point values. If so, this can be circumvented by case distinction in the calculation algorithm between "normal" and "at pole". However, it's not very important, in real world simulation we will rarely hit the poles exactly.
- There's a jumping sun reflection over the oceans. The rhythm and pattern seems to be the same as the rhythm and pattern many of us experience in microstutters in normal flight. Probably this can help to locate the reason of this everlasting issue. (I have really VERY high end PC dedicated only for Preper3D, and still have microstutters)

Shojom

[Shojom]

bcrawly57, yes and no.

Not limiting the framerate is the only certain approach to circumvent THIS OOM I have found for now, but there may be other scenerios leading to OOM state. And, not limiting the framerate may have impact in display quality, fluency and so on. You have to find out yourself your priorities.

Best solution, of course, is to hope for quick success at Lockheed Martin's Prepar3D development team to localize and correct the issue. They have a good starting point now.

Shojom

[golfcart22]

I have yet to be able to run P3d with unlimited frames without introducing blurry textures. Would love to hear from anyone who has solutions to running unlimited without blurries?

[Shojom]

No, sorry, golfcart22, I have no solution. Could You please stay on topic? Best if You could make the test described above and share Your result.

[Martyson]

I did a test this morning.
Took screenshots (if needed) to trap FSUIPC VAS readings, lat/lons etc during the test.
Tested from 0935am to 1040am

I used all my normal scenery Orbx, FSDT etc.
NVIDIA 376.09 11-29-16
FSUIPC4 registered, Version 4.958


I did not run any diagnostic software e.g. ProessExp64 ... just a normal P3D flight setup to test for OOM.
No RAMdisk in use
Normal yoke, pedals, throttles in use

Slew mode
Target FPS locked at 60
Alt 30000
SPD 40000
HDG from default airport
Aircraft Fury 1500
FSUIPC VAS start 2708648
FSUIPC VAS end 2617716

No OOM
No crash
No other problems to report


***********
MyPC-Specs:

Win7-PRO-64
Gigabyte Z170 motherboard
i7 6700- 4GHz LGA 1151 8MB cache CPU (4 Cores 8 Threads) No overclock , water cooled
16GB DDR4 Memory
500GB SSD Boot drive C (Crucial by Micron CT500 MX200 SSD)
2TB ST200 DM SCSI Hard drive F
GEForce GT 960 4GB Video card
Audigy SE Sound Card
750W Power supply
Antec Tower case
Blu-Ray RW CD LG BD-RE drive D
Viewsonic VX2250WM-LED 1080P Monitor
Viewsonic VX2250WM-LED 1080P Monitor

[Shojom]

Lucky guy!

I've never stated, that limiting frame rate will lead to OOM under all circumstances. My statement is that
1. There is at least one simply reproducible scenario in P3D leading to OOM state
2. This OOM is a builtin malfunction in Prepar3D
3. This OOM is a side effect of limiting the frame rate
and then described the test exactly enough to reproduce it. This is a standardized configuration (minFmaxP) and a standardized flight. When using other configuration and flight You will get other results. Several users have reproduced the test and have got same result. Reproducable tests are the most important precondition to help developers to localize and solve an issue.

Please make the test as described and share Your result. This will help in this case, other tests not.

Shojom