Board index FlightGear Release candidates 3.0

fg3.0rc1 memory usage

This is the archive of topics about the 3.0 release candidates.

Re: fg3.0rc1 memory usage

Postby KL-666 » Thu Feb 06, 2014 10:06 pm

Reading through the posts and from own experience, it looks like the biggest problem is high up, because then you "see" further, so more tiles are loaded in a square around the plane. Thinking of what i do at fl 400 is look forward, left and right, and only slightly backwards. But on the picture of loaded tiles in post http://forum.flightgear.org/viewtopic.php?f=68&t=21984&start=15#p200072 it shows a full square of tiles in memory.

Maybe it is an idea to clear the tiles behind the plane at half distance. Then you can cut off a quarter of the load in memory. At fl 400 i will certainly not miss them. At lower alts i do not know. But there the problem seems to be less. So if the rule for keep half distance tiles behind the plane starts at fl 100 or 200, i think a lot has been won.
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: fg3.0rc1 memory usage

Postby F-JJTH » Fri Feb 07, 2014 12:32 am

For information, I just got a feedback from a french user on the french forum who has exactly the same problem than described here.
Because the "Force 32 bits install on 64 bits system" is enabled by default he didn't touched it even if he has a 64 bits Win 7.

Now he has re-installed FG 3.0.0 RC in 64 bits and all crashes are gone, he noticed ~7.9 GB of memory load during a flight from LOWI to LFPO.

I'm more and more convinced that 64 bits installation is definitely required if you want to use Scenery v2.0
More feedbacks are welcome !

@Adrian: could you make the flight you described with a non-modified GIT version and report ?

Regards,
Clément
User avatar
F-JJTH
 
Posts: 697
Joined: Fri Sep 09, 2011 11:02 am

Re: fg3.0rc1 memory usage

Postby Thorsten » Fri Feb 07, 2014 6:59 am

So even if France custom "looks like" scenery v2.0 the content of the files is mostly different.


So we may be wasting half the memory with invisible triangles. In terms of visibility, that's a factor ~ 1.4 in visibility settings. I still could do 50 km in custom scenery on 32bit, which means if the triangles are the only issue, I should be able to do 35 on a 32bit with 2.0 scenery.

But I think the question is valid - if we create something that is significantly heavier but 'looks like' what we had earlier, there's something we're not doing right here.


For 3.0 release the solution would be to decrease our default "Bare" settings (preferences.xml) in order to be sure that we don't ask more than 2 GB of memory.
It seems that Bare = 4000 keep 1.8 GB of memory even after flying all over the Alps (mountains = lot of triangles)


This will get us hundreds of complaints that the terrain doesn't extend to the horizon - 4000 means we draw terrain 4 km around the aircraft (!). A recommendation to use 1.0 scenery on 32bit systems sounds more useful to me.
Thorsten
 
Posts: 11446
Joined: Mon Nov 02, 2009 8:33 am

Re: fg3.0rc1 memory usage

Postby Gijs » Fri Feb 07, 2014 7:05 am

Maybe we can have TerraSync check out the last "old" scenery revision in 32 bits? Preferably with a menu option so people could still switch to 2.0 scenery if they don't mind the lower visibility. Downside is that they won't get the latest objects, but I think that's favourable over memory crashes...
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9401
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: fg3.0rc1 memory usage

Postby adrian » Fri Feb 07, 2014 7:17 am

This is ridiculous. We can't make people switch to 64 bit systems. Besides, the memory requirements are just absurd. 10 GB to make a flight over Europe? We need to come up with a LOD system for the terrain, and fast.
Clement, can't test on regular git right now, but I'm sure I'd get the same results as you. Proposing solution; limit visibility to 40 miles out and LOD bare to 60000, reduce tile cache to half the regular size, make it cylindrical.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: fg3.0rc1 memory usage

Postby jomo » Fri Feb 07, 2014 7:51 am

I am not even convinced that the size of the memory is the big problem (as long as you do not try to use my "Apple II Plus" with 48KB RAM and max 360KB disk-space! :) ). To my knowledge the memory management was and is done by the Operating Systems - thus I would expect a "System Error" when there is not enough space -- not just a FGFS-Crash without any Error-Indication (and the OS still running)! I believe: Low memory (and/or 32bit or 64bit) would influence the speed -- not the pure technical function!

I now see lots of tests with real biggies of memory (and probably big sized engineering development PC's!) - but I miss some more details of what actually happens when FGFS crashes in that situation. That was what I tried to analyze with my test (see http://www.emmerich-j.de/TerSyn-Analysis.zip). But my knowledge is not good enough to even analyze what I see on these recordings: e.g. what exactly does the dependency between those curves tell me about the crash? (e.g. in http://www.emmerich-j.de/atc-6.ogv):
  • the Network Receiving does not show any problems
  • the Memory just raises from 2.8GB to 3.2GB - still 20% of memory is available! (and NO swap is used!)
  • only the CPU-Usage wants to exceed 100% - but does it often without any "crashes" (and also does it often with the current release and old scenery and heavy models etc. - that usually just reduces the fpm's drastically)
---> but actually FGFS crashes after ~9 Min !!!! NOT hours! And that can be repeated as often as you want!
There even is no actual error-indicator in the log - the Log only says: "Last I did (successfully?) was uploading stg's - and that I did already very often - without any problem!"

I am no expert on this -- but I do not see any relation of these Crashes to a memory-size-problem and/or 32 or 64k system. I do not even expect a System-Problem - because there is no System-Problem reported (in neither Operating-System) just FGFS crashes and the system works happyly ever after!

I really would hate to see FGFS staged - and tell customers "Stage 1 will only be supported till ... (3 years from now?) - then you need Stage 2 (version 3.0.0) plus a new PC!".
jomo / ATCjomo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 936
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: fg3.0rc1 memory usage

Postby Thorsten » Fri Feb 07, 2014 7:52 am

Proposing solution; limit visibility to 40 miles out and LOD bare to 60000


As far as I know out of the box the visibility is limited to 30 km out and LOD bare is also at 30000. You have to take action to increase the limits, and I don't see why we should prevent users from taking action.

Obviously, the range of options has now increased - we may have users on high end machines wanting new terrain, and we may have users on older 32bit systems wanting safe memory limits, so there's no one size fits all approach. We have to start from a reasonable default - not rock bottom, but not top of the line, and some users will have to change settings to get more out of the system, some will have to fall back to lower settings.

I don't think it's unreasonable to assume most users these days will run 64bit systems. It's been the standard for a few years now, any laptop you buy these days runs a 64 bit system. So asking people on old systems to take action isn't unreasonable.
Thorsten
 
Posts: 11446
Joined: Mon Nov 02, 2009 8:33 am

Re: fg3.0rc1 memory usage

Postby adrian » Fri Feb 07, 2014 8:15 am

Yes, I think it's unreasonable, there are lots of legacy systems running on 32 bit distributions, and there are very few people who can afford to have such large amounts of RAM. Forcing everyone to go 64 bit is just a hard idea, especially considering it's our fault the system has to use such large amounts of RAM in the first place. MSFS users have had view distances of 100 km since 2005 and didn't have to run 64 bit to see SRTM terrain. Bottom line, our approach is inefficient and we are pushing far too many triangles in memory, most of which are just tiny specs in the distance. A LOD system is necessary, unless you also think node culling is unneeded. And we need to stop using such ridiculous amounts of RAM for terrain which is not viewable. Unfortunately, there are very few people who are capable to come up and write a good LOD system, which means we must place hard limits like the LOD bare, unless you want a flood of bug reports in the tracker. But I didn't know LOD bare was 30000 to start with. I forgot that I had tweaked it. So this means that no more action is required on that part. On the other hand, visibility-miles controls the size of the cache, and there are two options: either rewrite the cache, or place a similar hard limit that must be manually lifted by the user.
(by rewriting the cache, I mean just reducing the size, which is just removing a "* 2" from a code line.)
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: fg3.0rc1 memory usage

Postby Thorsten » Fri Feb 07, 2014 9:41 am

Yes, I think it's unreasonable, there are lots of legacy systems running on 32 bit distributions, and there are very few people who can afford to have such large amounts of RAM Forcing everyone to go 64 bit is just a hard idea


I don't think we're doing that.

The current state of affairs is that we're offering two different sceneries for download, a lowres version and a hires version. If we recommend that people on 32bit systems use the lowres version, why is that a problem?

MSFS users have had view distances of 100 km since 2005 and didn't have to run 64 bit to see SRTM terrain.


I've been experimenting with 250 km visibility on a 32bit system in FG.

A LOD system is necessary, unless you also think node culling is unneeded. And we need to stop using such ridiculous amounts of RAM for terrain which is not viewable.


I'm all in favour of a LOD system.

I'm also all in favour of cleaning unneeded triangles from the scenery. I'm also all in favour of making a useful balance between resolution of terrain features and vertex count. Load on the vertex shader is just as much a problem as memory consumption.

My point is - none of this justifies emergency measures or alarm cries. The old scenery is still available, it will be available for the forseeable future, it works fine on low memory / low performance systems.

So some people can't use terrasync any more to get updates because that defaults to the new scenery. That is the only thing which will actually happen. So the new scenery in the current iteration works only for people with lots of memory. As long as we state it clearly and get the information out, I don't see the problem.

Just take a breath, if the new scenery doesn't work revert to old, and let's fix any issues with new scenery in good time. For years we've been sending the message to the scenery team that getting something out, even if it's not perfect, is better than nothing. Now we have something out, it's not perfect yet - if we now all clamor that they should have waited till it's perfect, we're sending the completely wrong message.

And a terrain LOD isn't easy. The best solution I see is to precompute it and store two resolution levels of scenery on disk. Because doing it on the fly is complicated. But then, loading tiles will slow down - which is the bottleneck for truly large visibility. I can get 350 km worth of CORINEscenery into my memory, but it takes more than 10 minutes to appear.

So let's just relax a bit, then talk about what we want to achieve and how to do it :-)
Thorsten
 
Posts: 11446
Joined: Mon Nov 02, 2009 8:33 am

Re: fg3.0rc1 memory usage

Postby adrian » Fri Feb 07, 2014 10:19 am

Thorsten wrote in Fri Feb 07, 2014 9:41 am:The current state of affairs is that we're offering two different sceneries for download, a lowres version and a hires version. If we recommend that people on 32bit systems use the lowres version, why is that a problem?

This is good, choice is always good.

So the new scenery in the current iteration works only for people with lots of memory. As long as we state it clearly and get the information out, I don't see the problem.


Well, no, there is a solution, because I just posted that I saw no more than 2.5 GB used on LSTA-LIPB over the Alps. And the solution is a one-liner, divide the cache size by two, removing unnecessary tiles from memory. So 32 bit users with up to 3 GB of RAM could use the new scenery without much problems, if they stick with a reasonable view distance.

I *am* relaxed, I'm just very scared that we're going to see a massive flood of false bug reports based on this issue. Very scary.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: fg3.0rc1 memory usage

Postby F-JJTH » Fri Feb 07, 2014 11:03 am

the limitation is 2 GB on Windows (see my msdn link above)
User avatar
F-JJTH
 
Posts: 697
Joined: Fri Sep 09, 2011 11:02 am

Re: fg3.0rc1 memory usage

Postby adrian » Fri Feb 07, 2014 1:06 pm

True, but I also did my test with 60000 meters LOD bare distance, which is twice the normal range.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: fg3.0rc1 memory usage

Postby Thorsten » Fri Feb 07, 2014 3:05 pm

And the solution is a one-liner, divide the cache size by two, removing unnecessary tiles from memory.


It probably was never intended for really large (>50 km) visibility - twice the range sounds excessive, I'd guess that visibility + 10 km (i.e. a constant value) would be a more reasonable default.

So - what are the bad side effects we might be getting? Is it only longer loading times when back-tracking?
Thorsten
 
Posts: 11446
Joined: Mon Nov 02, 2009 8:33 am

Re: fg3.0rc1 memory usage

Postby adrian » Fri Feb 07, 2014 3:18 pm

Tower view: needs a check for distance larger than ? -> disabled.
Disk IO is increased: if you fly back and forth a couple hundred of km, tiles will get paged in and out. At normal speeds you won't notice this, only with UFO or other superfast aircraft. Memory usage decreased by half or more: based on Clement's tests, by 150%. Can't look at the code now, maybe next week.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: fg3.0rc1 memory usage

Postby Thorsten » Fri Feb 07, 2014 3:35 pm

For what it's worth, I'd be in favour of at least trying this. If that's all there is to it, I see more benefits than loss.

Not that I could actually do anything about it...
Thorsten
 
Posts: 11446
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to 3.0

Who is online

Users browsing this forum: No registered users and 1 guest