Board index FlightGear Development Aircraft

737 Decent flying

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: 737 Decent flying

Postby asr » Sun Jan 19, 2020 7:02 pm

wkitty42 wrote in Sun Jan 19, 2020 6:14 pm:what version of FG, please? full version including year, please...


This happens both with the 2019.1.1 which is the current official release, and today I'm testing with a 2019.2.0 nightly build dated 2020-01-17.

I have added a custom nasal wrapper around maketimer() and setlistener() and there is no leak of either one (in the 737-800YV code). Both functions are only called during initialisation only.

Now I'll try to add a wrapper around setlistener() settimer() that measures the time it takes to execute the callbacks, to see if I can find one that is taking too long.

Edit: It's a nasal problem for sure. I can see the new "nasal" subsystem in 2019.2 taking 200+ ms everytime the jitter appears.
asr
 
Posts: 88
Joined: Mon Sep 15, 2014 8:55 pm

Re: 737 Decent flying

Postby V12 » Sun Jan 19, 2020 9:26 pm

2018.3.2 and 2019.1.2 too.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: 737 Decent flying

Postby asr » Sun Jan 19, 2020 11:50 pm

I've captured this:

Code: Select all
 1748.52 [ALRT]:event        +2     (+48ms).maketimer-[0x7ff9163b8ca0]-/Applications/FlightGear.app/Contents/Resources/data/Nasal/canvas/map/navdisplay.mfd:252  total   34.1s
 1748.52 [ALRT]:event        +4     (+48ms).maketimer-[0x7ff9179070e0]-/Applications/FlightGear.app/Contents/Resources/data/Nasal/canvas/map/navdisplay.mfd:252  total  33.21s
 1748.52 [ALRT]:event        +3     (+48ms).maketimer-[0x7ff9324acaa0]-/Applications/FlightGear.app/Contents/Resources/data/Aircraft/737-800YV/Models/Instruments/PFD/PFD.n  total  29.74s
 1748.52 [ALRT]:event        +36    (+48ms).settimer-/Applications/FlightGear.app/Contents/Resources/data/Nasal/local_weather/weather_tile_management.nas:1213  total  83.47s
 1749.02 [ALRT]:event      Subsystem nasal total  33.83s overrun 481.00ms


It happens every 1-2 secs that Nasal subsystem jumps to a very high value (481ms) in this case. Unfortunately the list on top looks like an absolute total and not the functions that caused this particular glitch.
asr
 
Posts: 88
Joined: Mon Sep 15, 2014 8:55 pm

Re: 737 Decent flying

Postby wkitty42 » Mon Jan 20, 2020 12:35 am

what happens if you set /sim/nasal-gc-threaded to false?
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: 737 Decent flying

Postby Richard » Mon Jan 20, 2020 5:52 am

In terms of the overrun warning " 1749.02 [ALRT]:event Subsystem nasal total 33.83s overrun 481.00ms" is the most information that is available as to the cause of the overrun. 481ms is quite a serious overrun.

Almost certainly the frame pause every 1-2 seconds is the Nasal Garbage collector. Often it is the canvas displays that are responsible for creating the garbage that needs to be collected and it is possible to avoid creating garbage in the first place by moving local variables into the class or module level - but it isn't easy to identify the causes.

The background GC isn't in 2019.1 - it's only in 2019.2 or later so /sim/nasal-gc-threaded will not be in the property tree.

Possibly worth trying with 2019.2 - however the background GC is still to be considered as experimental code and it is currently under investigation for causing FG to segfault.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: 737 Decent flying

Postby legoboyvdlp » Mon Jan 20, 2020 9:01 am

Asr, if you remove only the Canvas .Nas files do you still notice this?

I don't believe the 737 displays are using the more optimized A320 framework yet. It may be to do with how they are being run.

For context basically something is creating a lot of local variables, etc that is then being deleted by the garbage collector - which is a known bottleneck.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: 737 Decent flying

Postby asr » Mon Jan 20, 2020 10:42 am

Thanks for your answers, I'll try to find some time to continue diagnosing today.

For the record, the above logs come from 2019.2.0 (nightly), but the same issue is present in 2019.1.2 (official one). I haven't perceived a difference between both versions so don't look to me like it's caused/worsened by a feature added in 2019.2, i.e. background gc.

legoboyvdlp wrote in Mon Jan 20, 2020 9:01 am:Asr, if you remove only the Canvas .Nas files do you still notice this?

I don't believe the 737 displays are using the more optimized A320 framework yet. It may be to do with how they are being run.

For context basically something is creating a lot of local variables, etc that is then being deleted by the garbage collector - which is a known bottleneck.


I have tested with all displays disabled, the Aircraft's .nas that creates them being commented out from inclusion. It just makes the problem to appear later, but it's still there. That's what was making me think that this is not a problem of a particular nasal code but more of a problem somehow in the nasal engine that is more evident the more nasal code is run. In my last test I disabled local weather and that too made the problem appear much later.

It does look like GC. But the fact that is a cumulative problem and not a constant one, to me highlights that this is not caused by unoptimised nasal creating too much garbage, but rather the Nasal heap growing so that the GC pause gets longer and longer (more "live" objects to inspect which never get cleaned up). I'd like to have a look at how the GC works and what diagnostics are exported (if any).

I wonder if this could simply be some script appending to an array/list and forgetting to clean it up.
asr
 
Posts: 88
Joined: Mon Sep 15, 2014 8:55 pm

Re: 737 Decent flying

Postby Hooray » Wed Jan 22, 2020 9:42 pm

asr wrote in Mon Jan 20, 2020 10:42 am:I'd like to have a look at how the GC works and what diagnostics are exported (if any).


See: http://wiki.flightgear.org/How_the_Nasal_GC_works

I believe Richard reworked the GC to provide a new option so that it can be partially run outside the main loop.
Also, Richard mentioned on several occasions that he exposed additional Nasal GC at the property tree level, to track what's going on.
For details, I'd suggest to search the forum/commit logs or ask Richard directly. If in doubt, it might make sense to document those options on the wiki.

In addition, it might be a good idea to add such runtime info to the help/about dialog, or a dedicated "diagnostics" dialog, which should ideally also show if the new GC is enabled or not - possibly in conjunction with a checkbox (boolean) and a userarchive attribute, so that people can customize this on demand.

That being said, the number of active references/objects, as well as types/pools are fairly easy to retrieve from the GC, but there is some added complexity.
We can really only identify trigger points, but a GC run being triggered may not necessarily point to the line causing this.
As a matter of fact, the legacy GC defaults were far too inadequate for modern FG versions, i.e. pool size and other defaults can benefit from being customized, and possibly being exposed to the property tree.

Back when I last checked Nasal memory occupancy, it would require 16 MB of RAM, whereas the Nasal defaults were far too low.

Once these GC stats are exposed, it is also possible to plot those properties at runtime, and possibly add them to the OSG stats handler to tell what's going on.

Anyway, all that we can obtain at that point is the file name/line number last executed - which makes more sense to use for callback tracking (timers & listeners).

But like I previously said, exposing these Nasal internals at the property tree level would make sense for a number of reasons, i.e. better troubleshooting, but also fine-tuning/tweaking.
Given that we have a rather powerful autopilot/property rule system, we could even set up a dedicated PID controller instance to control currently hard-coded Nasal GC defaults at runtime by using frame rate and frame-spacing to drive the whole, which is an idea that both, James and Stuart repeatedly mentioned on the devel list in the context of benchmarking and dynamic feature scaling:

http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Feature_Scaling

Coming up with a property-tree interface for the built-in OSG/FGStatsHandler is another long-standing suggestion dating back to the early 2010s:

http://wiki.flightgear.org/OSG_on_screen_stats
http://wiki.flightgear.org/Towards_bett ... time_stuff
http://wiki.flightgear.org/Resource_Tra ... atsHandler
http://wiki.flightgear.org/Canvas_Troub ... _Osg_Stats

Given how well XML and the property tree work together, it would be kinda cool to provide a corresponding XML/property-enabled wrapper, so that arbitrary properties could be added to the OSG on-screen stats - at that point, exposing things like Nasal GC internals, would merely be a matter of turning C++ PODs into propertyObjects<>: http://wiki.flightgear.org/Howto:Use_Pr ... ee_Objects
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 737 Decent flying

Postby asr » Mon Jan 27, 2020 1:06 am

Well, after plenty of tests I am not sure if my changes to Nasal improved the symptoms, or the "next" branch of FG/SimGear has improved something a little. Now it does seem to be less noticeable, here's the data:

I've added a basic debug log to the GC so that it will print the total time spend for each GC. Here's my chart of a 4h + flight, broken in two, X axis is h:mm:ss Y axis is GC pause time in seconds (0.3 max):

Image
Image

This was a flight LEBB to ULLI, spending not more than 15 minutes in the ground and then climbing to FL350 in some good 25-35 min. I have absolutely everything disabled in rendering options, no scenery buildings, etc. and the route passes mostly over land:

Image
asr
 
Posts: 88
Joined: Mon Sep 15, 2014 8:55 pm

Re: 737 Decent flying

Postby Hooray » Mon Jan 27, 2020 10:28 pm

For stuff like this, it would make sense to create a dedicated startup profile so that settings can be easily reproduced, and then use a pre-recorded flight / flight plan or fgtape to easily run the whole thing as a benchmark.

Also, you may want to check the GC article on the wiki, it has pointers to several related patches, including one provided by ThorstenB that illustrates how to access GC internals like number of active objects/references - originally, this was used to determine how many additional symbols/references were added when new submodules were loaded.

It is trivial to expose these things as property and then use them in-sim for various benchmarking purposes.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 737 Decent flying

Postby asr » Mon Jan 27, 2020 10:44 pm

Here's the return flight, ULLI->LEBB, with Basic weather instead of Detailed Weather:

Except a short moment after 4h were I enabled Advanced weather during descent but noticed the hit on performance and returned to Basic.
Image
asr
 
Posts: 88
Joined: Mon Sep 15, 2014 8:55 pm

Re: 737 Decent flying

Postby chtadmin » Fri Jan 31, 2020 8:02 am

I am the author of the 737-300 that was copied by Soitenan and after breaking some important features and then posting many lies about what a great aircraft HE had created, somehow got it wedged into the default aircraft of fg. The original that I worked from (with permission) was done by Dave Culp ( a real life 737 pilot) and despite the plane being very incomplete when I started, had an excellent fdm which only needed some minor corrections in the C.G. and some minor Y and X axis weight distribution changes to get jsbsim to behave very realistically. I can tell you that it is an extremely well behaved and very easy and comfortable plane to fly. It was the first FG aircraft with a functional CWS autopilot mode, (just like the real aircraft) which after you learn what that is and what that does makes the plane even easier and simpler to fly. It was also the first FG aircraft to have A/P Auto-Disengage upon flight control deflection (just like the real aircraft). The autopilot is extremely powerful and simulates the actual 737-300 A/P quite accurately yet it is not difficult to learn . The aircraft handles well up to the limits of it flight envelope at most speeds and altitudes (as does the actual 737-300). As long as you pay attention to your airspeed and use the flaps properly at lower speeds its very difficult to get into trouble in the 737-300. The internal systems, i.e. fuel management and electrical systems, are not modeled in painfully intricate detail to the point of distraction while attempting to learn to fly an airliner. The point of my 737-300 was to create an entry level airliner that anyone with at least some experience with fg would be able to fly successfully without having to go through 2 months of type rating school. I believe I achieved that with the 737-300 I made. Don't get me wrong. It's not a "game" aircraft. You DO need to learn how to fly a 737-300 to fly it well but its not going to be a difficult road. I highly recommend you give it a try. It is very Nasal light and was developed on very old hardware yet yields good frame rates. Personally I find it a pleasure to fly.
Last edited by chtadmin on Fri Jan 31, 2020 8:55 am, edited 1 time in total.
ePilot
Charter Aviation
Any Plane, Any Route, Anytime
User avatar
chtadmin
 
Posts: 20
Joined: Sun Nov 24, 2013 10:22 pm
Callsign: CHT0001
IRC name: ePilot
OS: Debain 10

Re: 737 Decent flying

Postby KeithHadden » Fri Jan 31, 2020 8:39 am

I have been flying the 737 version created by epilot from almost the beginning. Up until then I was mostly flying props and turbo-props. I had tried out jets but battled to make any progress. Using the epilot 737 was a simple plane to learn, and it has now become my favourite and is my aircraft of choice. I used to fly on an old laptop and this version of the 737 never caused any framerate problems. I can totally recommend this version. Perhaps epilot can make it readily available for anyone to use.

Happy flying.,
CHT0019
Public Relations and Events - CharterVA
"Any plane, Any route, anytime"
KeithHadden
 
Posts: 33
Joined: Fri May 11, 2012 12:04 pm
Location: FAPE
Callsign: keith
Version: V2019.1.1
OS: Linux Mint 17

Previous

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 8 guests