Board index FlightGear Development Aircraft

Monitor system performance

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

Re: Monitor system performance

Postby Hooray » Mon Jul 14, 2014 3:00 am

good points there, we should add those to the wiki.
surprising that those optimizations Necolatis mentioned aren't internally already by JSBSim itself, maybe at least optionally using a corresponding flag ?

Gijs wrote in Sun Jul 13, 2014 7:25 pm:I'd definitely.need some more detailed instructions on that :-) I'm very interested in finding the source of it, as even a near empty FDM on the 744 seems to be heavier than any other complete aircraft.


have you checked your FDM in JSBSim's standalone mode, just to rule out any FG-specific issues, such as Nasal/AP/PropertyRules ?
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: Monitor system performance

Postby Gijs » Mon Jul 14, 2014 10:04 am

So, this morning I disabled all aircraft specific Nasal. The flight subsystem fluctuated around 10-100 total/ms. So the problem must be in the Nasal scripts. I then re-enabled script per script to find the culprit. Turned out it was the primary EICAS and more specifically, using setlistener on a property that is updated by the FDM (though outside /fdm/jsbsim; for example /gear/gear/position-norm). This is the opposite of Necolatis' "fault".

Disabling those listeners and putting the code in a loop, we're back to ca. 80 total/ms for flight (and the fps jumps up from 20 to 55) :-)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9384
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Monitor system performance

Postby Hooray » Mon Jul 14, 2014 10:08 am

Gijs wrote in Mon Jul 14, 2014 10:04 am:Turned out it was the primary EICAS and more specifically, using setlistener on a property that is updated by the FDM (though outside /fdm/jsbsim; for example /gear/gear/position-norm).


That kinda makes sense: the FDM will normally run inter-leaved, i.e. several iterations per frame, while Nasal will only be run once per frame. However, once you register a listener on a FDM property, Nasal will also be invoked at FDM rate. How much of an effect that ultimately has, depends on the nature of the code. However, even trivial code may run into GC issues, because the GC is a "global" thing, that may also be triggered for code registered elsewhere.

We could probably recognize such listeners, they have the potential of being possibly worse than settimer/maketimer(0.xx) calls ...
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: Monitor system performance

Postby hvengel » Mon Jul 14, 2014 4:47 pm

This is good info to know. I had not realized that this happened and I had assumed (I know shouldn't do that ever) that a listener that was looking at an FDM updated property would still run at frame rate and would respond to any changes to the FDM property at frame rate.

This seems like it could be a serious problem that could exist to some extent on a significant number of aircraft. If the Nasal system being invoked at FDM rate is at all heavy it will have a huge impact and a number of lighter systems could also have a very big impact. We have a number of notoriously resource consumptive aircraft (mostly air liners) that we seem to be unable to find the cause for the poor performance. Could this be an issue for these aircraft and has anyone checked?

It would be nice if we got some kind of warning or message (even if it was in the log) about listeners on properties that are updated at the FDM rate so that we could either remove them or, at least, confirm that they were light enough to not cause a significant performance hit. The only time it makes sense to have listeners respond at FDM rate is if the output of the listener is used by the FDM otherwise it is a waste of resources.

There are benefits to running FDMs at rates higher than the standard 120Hz. This is particularly beneficial to the landing gear simulation which helps with both ground handling and landings (less tendency to bounce for example) and if the FDM is performing correctly even moderate hardware can run at higher FDM rates. But any aircraft with Nasal listeners to FDM updated properties has the potential to have issues with FDM resource consumption that will prevent running the FDM at higher rates. So this is something that every aircraft dev should look at.

I also think that for any listened to property that is constantly changing (even things that change a frame rate) most listener code could run at a slower than frame rate and still be more than responsive enough. So in many cases using a timed loop will actually use significantly less resources than a listener running a frame or FDM rate without causing noticeable changes to what the pilot is seeing/feeling. One take away is that listeners should be used for things that change at < frame rate and for things that change >= frame rate use a timed loop unless the output of the function is used by the FDM (this should be rare).
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Monitor system performance

Postby Gijs » Mon Jul 14, 2014 5:28 pm

I used a listener because I assumed /gear/gear/position-norm would not be written to if there was no change from the previous value (I.e. no updates when the gear is not in transition). The more so because it is outside /fdm/jsbsim. Apparently JSBsim driven properties are constantly updated. Is that intentional?
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9384
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Monitor system performance

Postby Philosopher » Mon Jul 14, 2014 6:01 pm

You can add a flag to setlistener to have it run only when the value has changed, so that's not an issue. (It just isn't enabled by default – aka activate each write is the default behavior.)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Monitor system performance

Postby Hooray » Mon Jul 14, 2014 9:51 pm

Also, most JSBSim properties are still tied properties IIRC, i.e. directly bound to C++ pointers, which don't fire listeners.
There are several inconsistent concepts involved here and cleaning up this mess isn't exactly straightforward unfortunately.
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: Monitor system performance

Postby Johan G » Sat Jul 19, 2014 8:20 pm

Philosopher wrote in Mon Jul 14, 2014 6:01 pm:You can add a flag to setlistener to have it run only when the value has changed, so that's not an issue. (It just isn't enabled by default – aka activate each write is the default behavior.)

To a layman that is rather counterintuitive. I would for sure a listener to only react on changes. Thankfully it is documented somewhere.

Hooray wrote in Mon Jul 14, 2014 9:51 pm:...most JSBSim properties are still tied properties IIRC, i.e. directly bound to C++ pointers, which don't fire listeners.

Reading above posts, might that be an undocumented half thought trough safeguard? :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5545
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Monitor system performance

Postby punkepanda » Sun Jul 20, 2014 12:21 am

Thats "one" of those "crasy shit going on" I been taking about earlier.. Good to see you guys admit that it was a big bug this time.
Wonder when some of you will find out that those "small dots" street lights has a huge impact on framerate also. Why?
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Monitor system performance

Postby Hooray » Sun Jul 20, 2014 4:57 am

Johan G wrote in Sat Jul 19, 2014 8:20 pm:
Philosopher wrote in Mon Jul 14, 2014 6:01 pm:You can add a flag to setlistener to have it run only when the value has changed, so that's not an issue. (It just isn't enabled by default – aka activate each write is the default behavior.)

To a layman that is rather counterintuitive. I would for sure a listener to only react on changes.


Actually, it isn't: a listener responds to updates - it can only tell if there's been a change if it processes all updates. So it kinda makes sense once you think about it.
Imagine a real life analogy: a listener processing news announcements, it can only tell if there's new information announced if it's processing ALL announcements/news.
We have a number of way to trigger listeners by simply updating it with the same value.

And no, it's not a safeguard - "tied properties" were a performance hack over a decade ago, and even its creators called it a "brain fart" back then, tied properties are causing a lot of challenges in FG unfortunately. These days, people should normally be using propertyObject<> instead.
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 1 guest