Board index FlightGear Development Aircraft Flight dynamics model

Sometime, with Yasim... frame-rate is slow

Good sims require good FDMs (the "thing" that makes an aircraft behave like an aircraft).

Re: Sometime, with Yasim... frame-rate is slow

Postby Thorsten » Sat Feb 14, 2015 7:20 am

Thorsten is a great developer of OpenGL code and is doing a wonderful job with the ALS! But I believe that many problems that complain of FGFS are due to problems that can be solved. Meanwhile I want to anticipate that the developer EFA (Eurofighter), reading
this post has analyzed more carefully the code NASAL and found that the problem was related to an error in the NASAL code.


Did you read what I wrote? Did you check the numbers? Did you read what you yourself wrote?

I'm sorry, but that's just voodoo - you deactivated the Nasal subsystems of the plane and found no effect, so now you're anticipating that the developer will analyze the Nasal and find a problem? Based on what - that it didn't have an effect for you? Based on the small performance footprint of the events subsystem you plotted?

Whether I am a great GLSL coder or doing a crappy job is completely irrelevant for the question at hand (incidentially, I'm also one of the most experienced Nasal coders - AW is completely Nasal based). What matters here is that in order to solve problems, we have to follow where the data leads, not blame random subsystems.

1) So far, we're lacking hard evidence to prove that this is related/unrelated to Nasal


It persisted after de-activating the Nasal subsystem. We had a report NASAL code does not seem to be the cause, because it was all off. We have the performance monitor plots in addition. They all agree with my understanding how FG burns framerate based on my own performance tests.

I don't know about anyone else, but in my book that counts as evidence.

Not knowing much about fg coding in general, just generally speaking, a scripting language is not very efficient. So i wonder why fg leans so heavily on a scripting language like nasal.


Because if you have a task that consumes 0.01% of the total computational performance, it doesn't matter whether you do it efficient or inefficient - if you make it ten times faster, the framerate won't move a bit, and if you make it a hundred times slower, the framerate won't move either. Given that, you can priorize accessibility and ease of maintenance over execution speed.

(To give you a sense of perspective - the typical Nasal subsystem runs a couple of hundred lines per frame. Rendering at high quality runs about 1500 lines for each of your two million pixels every frame and loops over an array containing a good million vertices). That's about a factor of thirty million more operations per unit time. So FG doesn't lean 'heavy' on Nasal in terms of where the work is.

GLSL is the opposite case - that's where 99% to 99.9% of the computational cycles happen, so if you make it 20% faster, the framerate actually moves by 20%. Which is why rendering code frequently isn't accessible,but rather ugly and highly optimized.

Having said that, you can of course misuse Nasal to do heavy computing duty, in which case it eventually will slow down FG (if you inspect Nasal arrays with millions of entries every frame, it won't be a tiny amount of computation any more). But as long as you use Nasal for things that are not heavy-duty work (i.e. involving loops over thousands of entries, running code triggered by hundreds of listeners at the FDM rate...) the above argument holds.

The bottomline is - you need to optimize framerate by optimizing the part of the code where most performance is burned. Targeting subsystems with insignificant performance is pointless for optimization (still nice conceptually though...).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Sometime, with Yasim... frame-rate is slow

Postby Hooray » Sat Feb 14, 2015 2:26 pm

It persisted after de-activating the Nasal subsystem. We had a report NASAL code does not seem to be the cause, because it was all off.


like I explained previously, the way the OP "disabled" Nasal, only aircraft-specific scripts residing in that particular folder would be removed - I don't know about other scripts (embedded) or even system-wide stuff (like for instance AW or other stuff, we've had a number of users where system-level Nasal code would affect FG performance).

So no, evidence isn't complete/conclusive yet - which is why I suggested to 1) check your theory by disabling rendering using draw-masks, and 2) to check yasim standalone - both would be suitable to draw conclusions, without having to guess.

I'd say there are only 2-3 people around here who fully understand how to disable Nasal globally, as in "the Nasal subsystem" you are referring to above, which clearly didn't take place here.

And quite frankly, given that it would only take 30 seconds to check Thorsten's working theory of rendering being the main culprit/factor here (using the aforementioned draw masks) and another 30 seconds to verify if YASim standalone is exhibiting the same issues or not, I don't understand why we are even having this discussion. Therefore, I will remain out of this discussion until the OP reports back with these results, including preferably screen shots with OSG stats - which should help arrive at a correct conclusion, without it being inaccurate due to people misunderstanding the effects of disabling parts of a subsystem or not ...
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: Sometime, with Yasim... frame-rate is slow

Postby Thorsten » Sat Feb 14, 2015 2:48 pm

like I explained previously, the way the OP "disabled" Nasal, only aircraft-specific scripts residing in that particular folder would be removed - I don't know about other scripts (embedded) or even system-wide stuff (like for instance AW or other stuff, we've had a number of users where system-level Nasal code would affect FG performance).


We don't need that, because the OP isn't observing that the framerate is always low, he's observing that the framerate is in some situations low, whereas global Nasal just runs. Only the relative impact of airplane-specific scripts is hence interesting.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Sometime, with Yasim... frame-rate is slow

Postby abassign » Sat Feb 14, 2015 2:53 pm

The fact that the GPU do the bulk of the work is natural, modern flight simulators are trying give fully VFR experience to the pilot. Currently my machine has a last generation GPU (NVidia GTX 870M with 6GB of ram 1344 CUDA cores) I would certainly not hurt that allows for the graphical environment of FGFs in the best conditions and media video very large. This fact allows me to be able to concentrate on the code and particularly on the bottlenecks present in FGFs.

The example of EFA (Eurofighter) is very instructive, when I got to test the plane I noticed that his execution speed was very low, and that the GPU had little workload. I noticed, with surprise, looking at the "Performance Monitor", the load was increased by "Flight" which I deduce to be the system involved with FDM. I have some experience in simulation systems, I made a language in APL (which is an interpreter...) many years ago to create an efficient simulation system. I had been able to "touch" the problems of convergence that, if the system is misconfigured, may lead to incorrect solutions and/or very long time execution.

For that at first I thought that the problem was related to a bad parameterization dell'FDM. But at this point I had two sets of tests:

1. I deleted the references NASAL definition file initial and then, to make sure there was not some xml that attracted procedures NASAL, I renamed the directory that contains the code NASAL. I rerun the program, but the parameter "Flight" was always very high. Then, the programmer who follows the EFA, told me by e-mail that appeared to have substantially improved the code by removing a command NASAL setlistener ("/ gear / gear [2] / wow" ... As the setlistener is presumably activated all as often as you change the value "/ gear / gear [2] / wow", if this value is set to be a quick process as those dell'FDM, this is when the code NASAL relative, does not run 20-40 times more the second, but 120-140 times per second! This fact explains very well a dangerous point of "setlistener", which can give you many problems, or that substantially modifies the timing of the NASAL or other processes related to it. However, the change made I had no improvement, I do not know it could be a problem with the fact that there are many "setlistener" active in the code. at this point I thought maybe it would be better to define a variant of the "setlistener", a sort of "reaction time" That is, a limiter activation, which only after a certain minimum time, maybe defined as a global parameter in NASAL and / or as a parameter of the function itself. This "time" could be expressed in milliseconds, if "0" means that the function works as now, if 100, means that "setlistener" is activated only after a minimum time of 100 ms response. I find it very useful, even to simulate what happens in real life, for example if which want to simulate the delay time of a drive circuit warning etc ... Of course it is a finesse, but it seems very simple to implement and extremely useful to avoid the negative side effects of this important function NASAL.

2. I tried to see what happens to change a parameter YASim, and heuristically, I wanted to change randomly the minimum speed (<approch speed = "130" ...). This is a technique widely used by those who make the simulation when have doubts about the stability of the solution. Surprised if the value is very low (30), the parameter "flight" has decreased dramatically (from 132.63 to 0.34) with a consequent increase in the speed of the frame rate, of course, before reactivating the code NASAL!

At this point I think that the problem of the NASAL "setlistner" is one of the problems, but not the only one. I think there is also a problem of YASim, though, does not seem to be linked so much to the search time of the solution (the number of iterations of YASim both with value 130 or 30 is identical), but from some other weird because probably linked interface connection YASim with the system, but I honestly do not know :(

I will do other tests such as 757, I want to understand better. However I believe that these tests are important and should be done more frequently, otherwise FGFS can not compete with other serious simulators on the market.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Sometime, with Yasim... frame-rate is slow

Postby Hooray » Sat Feb 14, 2015 3:08 pm

listeners registered to FDM properties are generally problematic, and this is widely known actually: listeners are triggered whenever a property is updated/modified, Nasal listeners trigger Nasal callbacks, which is not native code, but scripted code having to invoke the garbage collector (GC) to check how many variables can be freed/recycled or need to be allocated afresh. This happening at FDM rate is problematic given our mark/sweep GC scheme.

But seriously, simply do what you've been told to do:

  • disable rendering using the aforementioned draw-masks, report back here
  • try YASim standalone, and report back here

If in doubt, just post another set of screen shots so that we can draw conclusions.

Your hardware/GPU seems indeed powerful enough - unless you have customized your default settings accordingly and ended up with some massive visibility.
Honestly, there are at least 2 people involved in this discussion now intimately familiar with how to troubleshoot such performance issues and to identify the real culprit - if you're looking for a solution, you are well-advised to simply listen to our advice and report back your findings. Because we can tell you exactly how to determine if your problem is rendering related, FDM related, Nasal related - or something completely else.

So far, you've been drawing misleading conclusions unfortunately, while failing to report back with the requested feedback, which means I am losing interest ... :?

If you don't understand what you are being asked to do, please just state so clearly - if in doubt, use your native language, so that another contributor can translate things, including our response then.


PS: You can combine listeners and timers - but it would make more sense to do this at the C++ level, but so far I find the discussion to be misleading, unless you have further evidence that you simply didn't post yet ?

Thorsten wrote:whereas global Nasal just runs. Only the relative impact of airplane-specific scripts is hence interesting.

given how timers, listeners and the GC may make FG non-deterministic, it is pretty hard to tell what is having an impact here - you are making this too simple - while you could definitely be right in this case, there's a plethora of scenarios where your assumption would fail you pretty bad.
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: Sometime, with Yasim... frame-rate is slow

Postby abassign » Sat Feb 14, 2015 3:47 pm

@Hooray, I would say that maybe this part of the discussion should place it in the NASAL forum, as this argument is relating to a problem of this programming language. I do think that this technical discussion haven't much interest to those who want to fly aircraft ...;) Anyway I'ill prepare something in future, but first I want to see how it is implemented listener code. However I think you could use a fixed timer, for example, every 10 ms, which makes a loop through scanning only listener objects that are active at a given time, at this point, if an object has changed its value, is modified a variable that counts the number of scan cycles, when they reach the minimum expected number of cycles of waiting, defined according to the waiting time requested, only then will the listener will be started effectively.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Sometime, with Yasim... frame-rate is slow

Postby Thorsten » Sat Feb 14, 2015 3:51 pm

Surprised if the value is very low (30), the parameter "flight" has decreased dramatically (from 132.63 to 0.34) with a consequent increase in the speed of the frame rate,


I suspect that's comparing a total value with an average frame value. Anyway, neither is apparent from any of your screenshots, and you still haven't answered the question what numbers you look at to base your conclusions on.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Sometime, with Yasim... frame-rate is slow

Postby Hooray » Sat Feb 14, 2015 4:21 pm

@abassign: Like I said, I wouldn't waste my time looking at Nasal unless you have hard evidence proving that this is indeed somehow related to Nasal. Equally, you don't need to look at listeners or timers: We perfectly understand how they work and what their limitations are. If a Nasal callback registered via a timer/listener is to be found problematic, it is not listeners or timers in general that are problematic, but their specific usage by the corresponding programmer. There really is no need to dig into this - if you are interested in understanding the problem and seeing it fixed/addressed, you would be well advised to follow up with the feedback we've been requesting - i.e. screen shots showing the performance monitor/osg on screen stats with rendering disabled using the draw-mask properties - and if that isn't conclusive already, and you are still convinced that there is a FDM level issue involved here, you could follow up with YASim standalone testing where Nasal/rendering would be excluded entirely. There is a reason why we are suggesting to proceed like this - it is the most sensible way given the resources we have. I am not interested in any speculation unless it is backed by numbers supporting your working theory.

Again, listeners and timers are not specific to Nasal, we have seen such issues even in C++ code - people just need to understand the concepts involved here.
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: Sometime, with Yasim... frame-rate is slow

Postby abassign » Sat Feb 14, 2015 6:02 pm

This is the problem for EFA (Eurofighter)

This first image show performance monitor with YASim param: <approch speed = "130" ...

Image

This second image show performance monitor with YASim param: <approch speed = "30" ...

Image

As you can see the simple change of the approch speed parameter has shocked the system and increased significantly the frame rate. I tested YASim alone, with the xml file on EFA and in both cases the number of cycles for convergence has always been the same: 351! I continue to believe increasingly that there is a problem in the interface between the system and YASim (Property Tree., NASAL ... I do not know ...).
I want a test, to perform YASim server as you can? So that it is completely outside the simulator and better divide the problem. What do you think?
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Sometime, with Yasim... frame-rate is slow

Postby Hooray » Sat Feb 14, 2015 6:16 pm

Via google translate:

Perché non è sufficiente seguire i consigli che abbiamo dato in precedenza ?

In particolare :
1 ) Disattivare il rendering visivo per vedere se questo influisce sulle prestazioni
2 ) Prova il FDM in modalità " solo" per vedere se è possibile riprodurre il problema o non
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: Sometime, with Yasim... frame-rate is slow

Postby Thorsten » Sat Feb 14, 2015 6:32 pm

As you can see the simple change of the approch speed parameter has shocked the system and increased significantly the frame rate.


So, I see that the framerate changed from 37 to 44. I also see that indeed flight in the second case uses close to zero resources, which in comparison with about any of the screenshots and performance tables you have on the first page prompts the question whether you managed to simply break it in some way.

I mean, suddenly getting an improvement of a factor 390 where all other cases you look at differ by a factor 3-4 at most certainly seems suspicious, but the suspicious thing is the low value, not the high value.

So - does it actually fly after your change?

Edit: Short test for flight subsystem mean execution time as function of plane on my box:

f16: 0.30
Cub: 0.29
777-200ER: 0.34
ec135: 0.57
f-14b: 0.28

Numbers seem to agree within a factor 2 with yours, i.e. are normal. And... I discovered by accident that a total execution time of 0.x (or a mean per frame time of 0.0) means that the FDM is defunct, i.e. your low framerate is because you just broke it somehow. I could reproduce that for the Cub as I choose an airport in which I spawned in water.

Bottomline: Yasim isn't broken and doesn't cause your low framerates.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Sometime, with Yasim... frame-rate is slow

Postby Johan G » Sat Feb 14, 2015 7:04 pm

I think this was mentioned briefly earlier, but what other things than only the FDM are attributed to the "Flight" submodule in the statistics?
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)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Sometime, with Yasim... frame-rate is slow

Postby Hooray » Sat Feb 14, 2015 7:38 pm

the "flight" subsystem will update fdm related properties - any code invoked by the FDM will thus also show up in the "flight" profile, including code triggered via listeners - which is why it is generally discouraged to register FDM listeners invoking Nasal code, because that makes the FDM non-deterministic, as the Nasal engine being invoked at FDM rate may mean that the garbage collector (GC) may be triggered, which means that duration of each FDM iteration may vary significantly. This is why it is generally favorable to use AP/property rules instead of Nasal for FDM coupled systems.
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: Sometime, with Yasim... frame-rate is slow

Postby Buckaroo » Sat Feb 14, 2015 8:48 pm

Changing a YASim approach value from 130 to 30 creates an FDM that is implausible for an aircraft like the Eurofighter. YASim often has no trouble creating solutions for such things, as it's largely a matter of adjusting drag and other factors to balance the allowable thrust for the two extremes of the flight envelope. But this will generate some crazy flight parameters, as can be seen by report values like "Lift Ratio" which will soar into bizarre realms.

I haven't traced what this does internally, but it's conceivable that such values result in simplified code execution. Even if true, it simply suggests that some unrealistic FDM configurations cause the simulation to do less work. It does not necessarily imply that a reasonable FDM should do the same work.

-Buck
Callsign: Buckaro(o)
Author: Lockheed 1049H Constellation, Grumman Goose, MD-81, Edgley Optica, Velocity XL RG, YASim Guide
User avatar
Buckaroo
 
Posts: 475
Joined: Fri Jan 18, 2008 7:45 am
Location: Bloomington IN USA
Callsign: Buckaro(o)
Version: 2.10
OS: Windows & Linux

Re: Sometime, with Yasim... frame-rate is slow

Postby abassign » Sat Feb 14, 2015 9:40 pm

Here instead I have made a check on the beautiful DHC6, and also in this case it is seen that the load of the GPU is relatively low (50-60%), but it has a high parameter "Flight" which tends to reduce the overall performance of system:

Image

I tried to run Yasim directly with the file dhc6.xml and I had these values:

Code: Select all
abassign@abassign-P15SM-A-SM1-A:~/fgfs/install/flightgear/fgdata/Aircraft/dhc6$ ~/fgfs/install/flightgear/bin/yasim dhc6.xml -a 3000 -s 100
This aircraft does not use the latest yasim configuration version.
Solution results:       Iterations: 1304
 Drag Coefficient: 17.284220
       Lift Ratio: 104.260559
       Cruise AoA: 2.561422
   Tail Incidence: -1.359083
Approach Elevator: -0.361199
               CG: x:-0.085, y:0.000, z:0.564

  Inertia tensor : 79429.453, -0.000, 204.822
        [kg*m^2]   -0.000, 23331.586, 60.101
     Origo at CG   204.822, 60.101, 98913.227


In this case the number of iterations (1304) is the limit and could be the cause of the high value of "Flight", probably working on the parameters you can improve the solution proposed by YASim. Or switch to JSBSim all could improve.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

PreviousNext

Return to Flight dynamics model

Who is online

Users browsing this forum: No registered users and 5 guests