Jump to content

Sign in to follow this  
Petraeus

Version 2.1 OOM and possible memory leak.

Recommended Posts

You can dislike my comments all you want, but I am putting my money where my mouth is.

 

I don't believe in "luck" when it comes to software. Once again, we'll just move the goalposts since that's easier than confronting the actual evidence being presented.

 

Lucky...are you kidding me ?

 

EDIT; I just want to add, I want to see what the issue here is too. This is the most boring thing I've done in months, but I am doing it for a reason. Just handwaving away the fact that I am running max veg and nowhere near an OOM after 2 hours isn't cool. Let's do away with the dislikes and other such and try to figure it out.

 

Or you can return to insisting this issue is something that it quite obviously isn't. That's up to you.

  • Upvote 1

Regards,

Brian Doney

Share this post


Link to post

 

 


Lucky...are you kidding me ?

 

Napoleon, when presented with a new general, would ask, "Is he lucky?"  I don't know if Napoleon actually believed in luck, but on a battlefield if someone's always in the right place at the right time, he might be considered lucky, although the real reason is that he understood the principles of war better than the average general.

 

"Lucky" is a tricky thing to pin down, but I'd say you were as lucky as those generals Napoleon was talking about. :)

 

Hook


Larry Hookins

 

Oh! I have slipped the surly bonds of Earth
And danced the skies on laughter-silvered wings;

Share this post


Link to post

Well, I apologize for letting a bit of my frustration show, but this is exactly what I alluded to earlier, and is also what happened last time I did extended tests of P3D.

 

It's never enough to just show something can be done. There are always 100 caveats, and the more conclusive your evidence, the more hand-waving occurs. 

 

I'll consider this test concluded from my point of view. If someone comes up with a better scenario, I'm open to it. I'd like to talk with Jim more to compare notes, as I do believe he is the only other person testing bone stock.


Regards,

Brian Doney

Share this post


Link to post

So Fr.Bill. Is at all possible for any of theses errors to cause a memory leak or excessive VAs usage?

No, errors in an XML "gauge script" will simply not be completely evaluated. They will work up to the error and then simply skip over the rest.

 

However, that's not to say that poorly coded XML even when supposedly operating normally cannot cause problems. The same applies to C and C++ compiled gauges.

 

The way to test if any particular aircraft's gauges are causing problems would be to simply substitute an essentially blank panel.cfg temporarily...


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

No, errors in an XML "gauge script" will simply not be completely evaluated. They will work up to the error and then simply skip over the rest.

 

However, that's not to say that poorly coded XML even when supposedly operating normally cannot cause problems. The same applies to C and C++ compiled gauges.

 

The way to test if any particular aircraft's gauges are causing problems would be to simply substitute an essentially blank panel.cfg temporarily...

 

What about a situation where you have dependencies between XML gauges ? 

 

A situation where one bit is waiting for the other bit to write but it never does as it doesn't parse ?

 

Am I talking out of my nether regions again ?


Regards,

Brian Doney

Share this post


Link to post

 

 


Taken just now.
This isn't a leak. This is people running incompatible addons, or a combination of settings that have been warned against from the start.

 

 


Yes, brian is lucky, it doesn't affect him, truth be told, it doesn't affect me if I'm willing to live with a 3nm or so circle of tree coverage (which I am, till LM fix it, but I do want them to fix it, and soon)

 


Napoleon, when presented with a new general, would ask, "Is he lucky?" I don't know if Napoleon actually believed in luck, but on a battlefield if someone's always in the right place at the right time, he might be considered lucky, although the real reason is that he understood the principles of war better than the average general.

 

I'm sorry but you all are not reading and counting correctly.  Brian had much less VAS than I had and the FSUIPC program was going ballistic with it's dinging (post 82).  I started out with over 2 GB's of VAS.  Brian's gauge does not even hardly register any VAS left.  The first gauge reading:

742588 KB = 0.708GB

2nd gauge reading:

739264 KB - 0.705 GB or 722 MB's

3rd gauge reading:

682960 KB = 0.651 or 667 MB's

and the last one (going over the lake):

866976 KB = 0.827 GB or 847 MB's (yes he got more VAS here but still in dangerous territory for an OOM.  When it gets down to the 430000 KB area, then he should be hearing the dings from FSUIPC.  Don't know when Bob's beeps or dings go off.  I would expect the same).

I used the following link to look up the number of KB's - http://www.whatsabyte.com/P1/byteconverter.htm.

 

Less than 1GB of total VAS is okay?  Out of 4GB's of virtual address space?  So Brian has proven there is a problem too.  Like I said, I started off with over 2GB's of VAS when I first started up P3D but it depleted fast. 

 

I'm finished here as I have done my job of proving the loss of VAS with the vegetation slider even up to the normal level.

 

Best regards,


Jim Young | AVSIM Online! - Simming's Premier Resource!

Member, AVSIM Board of Directors - Serving AVSIM since 2001

Submit News to AVSIM
Important other links: Basic FSX Configuration Guide | AVSIM CTD Guide | AVSIM Prepar3D Guide | Help with AVSIM Site | Signature Rules | Screen Shot Rule | AVSIM Terms of Service (ToS)

I7 8086K  5.0GHz | GTX 1080 TI OC Edition | Dell 34" and 24" Monitors | ASUS Maximus X Hero MB Z370 | Samsung M.2 NVMe 500GB and 1TB | Samsung SSD 500GB x2 | Toshiba HDD 1TB | WDC HDD 1TB | Corsair H115i Pro | 16GB DDR4 3600C17 | Windows 10 

 

Share this post


Link to post

Well that's really a shame.

 

I agree, that less than 1 GB of VAS is low, and that's why I don't run Extremely Dense, or if I did, I would follow LM's advice and keep LOD radius in check.

 

I guess you are correct, you have proven that higher settings result in lower available VAS, but the point is, it will stabilize, which I have proven.

 

The headshot is in post #133, where a properly working system returned VAS as I flew out over the water and left the autogen behind.

 

If LM has made any mistake, it is in allowing for such high autogen and LOD settings to be use simultaneously.

 

I'm sorry if I frustrated you, and I hope you realize my comments made in frustration were absolutely not directed at you. I'd hoped we could look further since I do trust you are running a stock sim. I hope you will reconsider.


Regards,

Brian Doney

Share this post


Link to post

What about a situation where you have dependencies between XML gauges ? 

 

A situation where one bit is waiting for the other bit to write but it never does as it doesn't parse ?

XML scripts are not as "dependent" as C gauges are. If any one gauge is waiting on something from another, they will simply skip along and ignore the absent value without causing any issues at all. Edited by n4gix
Added "not" to a phrase

Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

 

 


If LM has made any mistake, it is in allowing for such high autogen and LOD settings to be use simultaneously.

 

Well, as I recorded above in post 131, I checked to see if lowering the settings would help.  They didn't. I still struggled for VAS.

 

Best regards,


Jim Young | AVSIM Online! - Simming's Premier Resource!

Member, AVSIM Board of Directors - Serving AVSIM since 2001

Submit News to AVSIM
Important other links: Basic FSX Configuration Guide | AVSIM CTD Guide | AVSIM Prepar3D Guide | Help with AVSIM Site | Signature Rules | Screen Shot Rule | AVSIM Terms of Service (ToS)

I7 8086K  5.0GHz | GTX 1080 TI OC Edition | Dell 34" and 24" Monitors | ASUS Maximus X Hero MB Z370 | Samsung M.2 NVMe 500GB and 1TB | Samsung SSD 500GB x2 | Toshiba HDD 1TB | WDC HDD 1TB | Corsair H115i Pro | 16GB DDR4 3600C17 | Windows 10 

 

Share this post


Link to post

Well, as I recorded above in post 131, I checked to see if lowering the settings would help.  They didn't. I still struggled for VAS.

 

Best regards,

 

I'm not positive if this would be related, but LM have also mentioned that a reload is often required after making changes in the menus. Not really sure, and I don't claim that this is definitely the case here.

 

If we look at the differences, I did fly the Beech, you were in the Raptor. It might be that the speed factor comes into play there, but that somewhat supports the idea behind having different graphics profiles for different types of flying.

 

LM did not go into this much detail, but my impression from what they have said, is that it is entirely possible to overload the engine using sliders and default scenery alone, and that it is up to us to work to find balance between LOD radius and autogen density for the type of flying we will do. It may very well be that with an advanced addon aircraft, Extremely Dense might always be 100% off limits. That's not really a surprise to me, as the number of objects is really quite over the top over such a large area, in my opinion.

 

If someone wants to disregard LM's advice and use high LOD and autogen settings together, well, in that case I think that the only thing that might need fixing are the options made available to us. 

 

For full disclosure, I flew that test at an LOD of 4.5. Had I run 6.5 I have no doubt I would have had an OOM, but, I wouldn't do that, since I have already been warned not to. Were I to have been in an advanced addon aircraft, I likely would have had an OOM as well. I think the difference of opinion we are having is, that this makes perfect sense to me, and is simply a compromise that must be made as long as we are working with 32bit.

 

I hope if nothing else, that I have at least shown that there is likely not a leak

 

I guess, in the end, that was my point from the beginning. If your addon a/c is incompatible or chews up 1GB of VAS all by itself, or if you are running settings above what has been recommended ( or all of the above, as I feel is likely in most of these reports ), how can the resulting OOM be considered a bug ? Or even a surprise ? 


Regards,

Brian Doney

Share this post


Link to post

So now we have to worry about frame chasers and slider chasers ????  :lol:  :lol:  :lol:

Share this post


Link to post

To compensate for the lack of trees (which I rarely see anyways) a setting of sparse allows me to complete most flights

 

AND set 12 layers in AS2012 which makes for some nice clouds at least (IMO)

Just did a KJFK to CYHZ with FsDreanTeam KJFK and Simaddons CYHZ and FTX_Vector with AS2012 at 12 layers in REX4_1024 clouds

 

Never a burp and landed the AXE at CYHZ in zero viz  (snow storm)

 

All for the want of trees... could not see any anyways with that snow falling....

 

2.5G RAM usage at departure, 2.7 G upon approach

 

 

Allen


                 MSFS2020 now RULES the SKIES

                                                  Allen  Lavigne    in   Canada

 


 

Share this post


Link to post

No, we still have to worry about VAS.  That's what is being depleted for some reason and fairly fast.  I was going to mention earlier though that back when FSX/FS9 were first released, everyone was looking at the FPS counter.  Now we have tools to be constantly monitoring the amount of VAS thanks to COL (Ret) Bob Scott and Pete, the developer of FSUIPC.

 

Best regards,


Jim Young | AVSIM Online! - Simming's Premier Resource!

Member, AVSIM Board of Directors - Serving AVSIM since 2001

Submit News to AVSIM
Important other links: Basic FSX Configuration Guide | AVSIM CTD Guide | AVSIM Prepar3D Guide | Help with AVSIM Site | Signature Rules | Screen Shot Rule | AVSIM Terms of Service (ToS)

I7 8086K  5.0GHz | GTX 1080 TI OC Edition | Dell 34" and 24" Monitors | ASUS Maximus X Hero MB Z370 | Samsung M.2 NVMe 500GB and 1TB | Samsung SSD 500GB x2 | Toshiba HDD 1TB | WDC HDD 1TB | Corsair H115i Pro | 16GB DDR4 3600C17 | Windows 10 

 

Share this post


Link to post

 

 


For full disclosure, I flew that test at an LOD of 4.5. Had I run 6.5 I have no doubt I would have had an OOM, but, I wouldn't do that, since I have already been warned not to. Were I to have been in an advanced addon aircraft, I likely would have had an OOM as well. I think the difference of opinion we are having is, that this makes perfect sense to me, and is simply a compromise that must be made as long as we are working with 32bit.

 

Good info Brian but I posted above that I did lower my LOD_Radius to normal (not sure what the LOD would be) and reduced the Texture_Max_Load to 1024.  It was slower in degrading VAS but by the time I had reached Washington, it was in the 430000 which is about where the FSUIPC module starts warning of an OOM.

 

Best regards,


Jim Young | AVSIM Online! - Simming's Premier Resource!

Member, AVSIM Board of Directors - Serving AVSIM since 2001

Submit News to AVSIM
Important other links: Basic FSX Configuration Guide | AVSIM CTD Guide | AVSIM Prepar3D Guide | Help with AVSIM Site | Signature Rules | Screen Shot Rule | AVSIM Terms of Service (ToS)

I7 8086K  5.0GHz | GTX 1080 TI OC Edition | Dell 34" and 24" Monitors | ASUS Maximus X Hero MB Z370 | Samsung M.2 NVMe 500GB and 1TB | Samsung SSD 500GB x2 | Toshiba HDD 1TB | WDC HDD 1TB | Corsair H115i Pro | 16GB DDR4 3600C17 | Windows 10 

 

Share this post


Link to post

Good info Brian but I posted above that I did lower my LOD_Radius to normal (not sure what the LOD would be) and reduced the Texture_Max_Load to 1024.  It was slower in degrading VAS but by the time I had reached Washington, it was in the 430000 which is about where the FSUIPC module starts warning of an OOM.

 

Best regards,

 

Well, maybe it is the Raptor then, I don't know.

 

It's getting a bit late tonight, so I will try it tomorrow if I have some time. I feel that it doesn't really matter though, as at such high settings, I'd expect to be on the edge. If you eventually settled at 100 MB free, but it did eventually settle, then that still isn't a leak, just a sign that settings will need to be compromised.

 

The fix ? Lower the slider  :P

 

I was just messing around again, and the number of objects is staggering at full right sliders. I'd only briefly tried it there right after release of 2.0, and only to slew around a bit. This was the first time that I'd actually tried flying with it set so high. I guess I just don't understand why this is such a mystery. 

 

LM have given us the options to fully break the engine if we adjust these options carelessly. 

 

YAY A CAR ANALOGY !

 

It's like LM brought us a restored Charger, that they'd added some shiny bits too, with the clear instructions that we could do one of two things*:

 

1) Go fast.

 

2) Turn corners.

 

...but never both at the same time.

 

From my perspective, half of the sim community have gone careening off the road at the first bend, and are trying to blame the car !  :lol:

 

Anyway, have a good night, I'll try to break it some more tomorrow. 

 

 

*not unlike most American cars  :lol:

  • Upvote 1

Regards,

Brian Doney

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
  • Donation Goals

    AVSIM's 2020 Fundraising Goal

    Donate to our annual general fundraising goal. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.


    30%
    $7,720.00 of $25,000.00 Donate Now
×
×
  • Create New...