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

[Hooray]

you definitely have quite a bit of eye candy stuff running there, so to re-iterate again, this is the best option to exclude rendering entirely:
Subject: Sometime, with Yasim... frame-rate is slow

But to check Thorsten's suggestion, you can use draw-masks to disable rendering:

http://wiki.flightgear.org/Troubleshoot ... up_profile

Beginning with FlightGear 3.1+, you can also toggle individual scenegraph traversal masks on/off (these can be changed at runtime using the Property browser:
--prop:/sim/sceneryloaded-override=1
--prop:/sim/rendering/draw-mask/terrain=0
--prop:/sim/rendering/draw-mask/aircraft=0
--prop:/sim/rendering/draw-mask/models=0
--prop:/sim/rendering/draw-mask/clouds=0

To check your own theory, please consider running YASim in standalone mode with just the FDM. That is the only reliable method to see if there are FDM-level issues involved or not.

[Buckaroo]

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.

The number of iterations has little to do with in-flight performance. Your own findings should have suggested this. You ran the Eurofighter with different approach settings and found different results, yet the number of solver iterations was unchanged.

Solver iterations can give an indication of how much trouble the solver had determining if the stabilizer is sufficient to balance pitching moments at both approach and cruise, but that's all. It is not a useful indicator for process performance.

-Buck

[Thorsten]

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:

Right - we see a completely normal duration of the flight subsystem with 0.40 ms/interation in this screenshot. You can fit 2500 of those into a second, so it remains a mystery to the rest of us why you think this is what drags your framerate.

I have frankly no clue what the GPU utilization as shown in the NVIDIA app actually measures, but given that it runs a vertex pipeline, a rasterizer stage and a fragment pipeline (and a couple of smaller things), any of these can be the bottleneck. So you may end up with a GPU not utilizing all its cores and still being the bottleneck. But I trust you can use a pocket calculator and check that the total/ms column of the performance monitor doesn't add up anywhere close to a second.

Or switch to JSBSim all could improve.

In your own test, the F-14b JSBSim FDM utilized 0.59 ms per iteration. With 0.40 ms/iteration, the DHC6 is 50% faster. This is a completely bizarre statement you're making here. Why are you even trying to measure numbers if you don't care what they are because you want to blame YaSim?

[abassign]

I made a change to the code YASim in order to get the actual execution speed dell'FDM, I hope that this code can be inserted in the official git because I think it is a useful aid for closer monitoring of the parameters. I included two examples, the first is related to the Eurofighter and the second to DHC6:

Note: I have inserted the line: "CPU Iter. Time:" to show the time in ms all'FDM need to find the solution. Since the average FDM runs 100-120 times every second, on my machine, I preferred to to insert the multiplication x 100 to give an concept of the total time required every second. The value "time for iteration" is the time required by the CPU in microseconds (us).

Yasim Eurofighter cpu speed test with param: <approach speed="30" aoa="9">

Code: Select all

YASim Solution results
       Iterations: 351
   CPU Iter. time: 0.11963 ms (11.96 x100) time for iteration: 0.34 us

 Drag Coefficient: 11.909696
       Lift Ratio: 4713.267578
       Cruise AoA: -0.512621
   Tail Incidence: -0.284141
Approach Elevator: -0.011375
               CG: x:-9.642, y:-0.000, z:0.087

  Inertia tensor : 39099.188, 2.326, 5263.448
        [kg*m^2]   2.326, 159295.875, -0.037
     Origo at CG   5263.448, -0.037, 188226.859


Yasim Eurofighter cpu speed test with param: <approach speed="130" aoa="9">

Code: Select all

YASim Solution results
       Iterations: 351
   CPU Iter. time: 0.11968 ms (11.97 x100) time for iteration: 0.34 us

 Drag Coefficient: 12.546452
       Lift Ratio: 220.451385
       Cruise AoA: 0.729339
   Tail Incidence: 0.450501
Approach Elevator: 0.045810
               CG: x:-9.642, y:-0.000, z:0.087

  Inertia tensor : 39099.188, 2.326, 5263.448
        [kg*m^2]   2.326, 159295.875, -0.037
     Origo at CG   5263.448, -0.037, 188226.859


Yasim Eurofighter cpu speed test with param: <approach speed="230" aoa="9">

Code: Select all

YASim Solution results
       Iterations: 678
   CPU Iter. time: 0.23305 ms (23.31 x100) time for iteration: 0.34 us

 Drag Coefficient: 12.009978
       Lift Ratio: 59.845356
       Cruise AoA: 3.523851
   Tail Incidence: 0.646575
Approach Elevator: 0.166401
               CG: x:-9.642, y:-0.000, z:0.087

  Inertia tensor : 39099.188, 2.326, 5263.448
        [kg*m^2]   2.326, 159295.875, -0.037
     Origo at CG   5263.448, -0.037, 188226.859


Yasim Eurofighter cpu speed test with param: <approach speed="330" aoa="9">

Code: Select all

YASim Solution results
       Iterations: 1201
   CPU Iter. time: 0.40928 ms (40.93 x100) time for iteration: 0.34 us

 Drag Coefficient: 11.789522
       Lift Ratio: 18.964622
       Cruise AoA: 7.932158
   Tail Incidence: -6.921604
Approach Elevator: 0.298966
               CG: x:-9.642, y:-0.000, z:0.087

  Inertia tensor : 39099.188, 2.326, 5263.448
        [kg*m^2]   2.326, 159295.875, -0.037
     Origo at CG   5263.448, -0.037, 188226.859


Yasim DHC6 cpu speed test:

Code: Select all

YASim Solution results
       Iterations: 1304
   CPU Iter. time: 0.20395 ms (20.40 x 100) time for iteration: 0.16 us       
                                                                                                                           
 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


Comment:

Meanwhile, it is evident that the DHC6 has a better optimization for single loop because each loop cycle lasts 16 us compared to 34 which is observed for the Eurofighter. But the DHC6 employs hes about 1304 cycles compared to 351 required by Eurofighter.
The solution dell'FDM may deviate greatly varying one parameter, this means that the "boundary conditions" are fundamental and should be chosen attentively.

After this test it is clear that the parameter "Flight" is only partly related to the effective execution speed of the FDM loop solution. It would be interesting to know where is built the parameter "Flight" and if there is a link to "Events". In fact, I noticed that the higher "Flight", is on average higher "Events". Can indicate which is the code that implements the "Performance Monitor"? I think looking at that code, can understand something more.

I think it is useful to include the function that calculates the time loop for better optimization, if you're interested I can show you the code in another post, are just a few lines.

[Hooray]

Can indicate which is the code that implements the "Performance Monitor"? I think looking at that code, can understand something more.

Quite frankly, I could answer all of your questions and post tons of pointers, but I am really not getting the impression here that you are even reading what we are telling you !?
There's some very simple steps that you should follow for troubleshooting this - so far, you've been skipping pretty much everything we told you - while either discarding our advice, or re-discovering what we told you previously.

[Thorsten]

I think it is useful to include the function that calculates the time loop for better optimization,

To quote the person who knows earlier in the thread:

I suspect you misunderstand YASim solutions. YASim calculates a "solution" once, when the FDM is initially loaded. This produces static values that are used for the entire Flightgear session. They are not re-calculated during the session.

I think we can drop 'suspect' now - you misunderstand how YaSim works, period.

[Hooray]

besides, Buckaroo wrote the YASim guide: http://www.buckarooshangar.com/flightgear/yasimtut.html

[abassign]

There are two phases in YASim, the first compile () and the second solve (), the compile phase is performed for the preparation of the tables, and solve () to the solution of differential equations. I measure the CPU time used in the While loop inserted in the method Solve ().

I'm doing the test you recommended, but first it seemed useful to know the real CPU load during the cycle calculation dell'FDM, the number of cycles is not enough is clearly insufficient to understand, so I added the code measurement. And in fact, I have noticed that the cycle time for the EFA is significantly higher than that of the DHC6, despite the fact that apparently is more simple parameterization. While the number of cycles of convergence for the DHC6 is greater (1304) compared to EFA (351).

I'm glad to know that you are so experts, but apparently nobody was able to explain clearly why so much CPU time is spent by "Flight" ... and because it is simple enough to change a parameter for EFA that time automatically execution of "Flight" collapses!

For my programming experience this means that there is a problem somewhere in the code. Such as, for example, during this discussion, we have discovered a problem of a function NASAL.

If I have not passed the test data that you're asking, is because they are surprisingly contradictory and therefore need to be improved in order to give you information that is as clear as possible.

I was surprised by the transfer of the discussion in a different forum, but in a nice way, because I think this is the most appropriate forum, sorry if I did not use this space from the beginning. And of course, excuse my vehemence, but apparently it is not only my ... I think this is a typical side effect of who does the programming of computers!

[Hooray]

• we only asked you to disable rendering entirely using the aforementioned settings (draw-masks)
• we also suggested that you run the FDM using the YaSim standalone FDM (without fgfs)
• once/if you can reliably reproduce a problem, it would make sense to share a pre-recorded flight and/or fgtape so that we can check what's going on

I think we've posted plenty of advice on troubleshooting this - so far, I am not seeing much in terms of the requested feedback unfortunately.

PS: And no, I am afraid, that we haven't "discovered" any problematic Nasal functions at all - the underlying details are actuall pretty well known, registering listeners to be invoked by FDM properties is generally frowned upon. If anything is problematic at all, it is the fact that the property tree doesn't show warnings optionally whenever that is being done - equally, registering identical listeners (=callbacks) is a common mistake people are making, which may significantly add to performance issues - not just in Nasal space, but even in C++ space.

[abassign]

How do you see the second point was carried out, although it has need to alter the code YASim to have measures that would serve to something because the only knowledge of the number of cycles is not enough, as shown in the case of DHC6 (Many cycles but time running short ...). As you see, I work so a little different from other ... now I go forward in the second phase of the test, I must to understand the real significance of the parameter "Flight"!

[Hooray]

We can explain to you exactly how SGSubsystems are invoked and how the performance monitor/profiler works - but you'd be well-advised to proceed step by step here - or you'd be wasting time, and not just your's I may add

[Buckaroo]

There are two phases in YASim, the first compile () and the second solve (), the compile phase is performed for the preparation of the tables, and solve () to the solution of differential equations. I measure the CPU time used in the While loop inserted in the method Solve ().

I fear I'm losing my implacable calm.

In simple terms, YASim does this:

Code: Select all

  initialize phase:
    parse the configuration file
    compile the aircraft elements into the necessary mathematical structures and data
    solve for auto-generated values not set in the configuration file
    terminate if valid values could not be generated
 
  flight phase:
    while not crashed and not done do:
      routine flight calculations



All of this is evident in the source files, though admittedly they're not always exactly elegant and intuitive.

If you want to evaluate execution time during flight, you must place your execution counter inside the flight calculations, not the initialization stuff. The "solve" component is not part of flight and will tell you nothing of relevance.

-Buck

[Thorsten]

I'm glad to know that you are so experts, but apparently nobody was able to explain clearly why so much CPU time is spent by "Flight" ... and because it is simple enough to change a parameter for EFA that time automatically execution of "Flight" collapses!

First, the assertion that 'so much CPU time is spent on flight' is not true according to your own data, so naturally we can't explain it. It's like complaining that nobody can explain to you where the green color of the sky comes from - I can't explain an assertion that's counter to fact - no one can.

Remember - the FDM mean execution times were all completely normal:

I don't see how you judge FDM performance. The for the 757 you write load of FDM is too high and it has a mean value of 0.60 ms per iteration shown. For the F-14b, you comment on its excellent performance and we find the flight subsystem comes to a mean value of 0.59 ms - so it is 0.01 milliseconds faster and that's the difference between 'too high' and 'excellent performance' ? The F20 has a mean value of 0.34 ms, i.e. much better than the F-14b - yet you see room for improvement?

Second, the problem is also not that nobody was able to explain how you can make the FDM execution time go to zero - the problem is simply that you didn't read the explanation. Let's try it again, shall we?

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.

Okay, I have given your observation some attention, I've convinced myself that YaSim is sound and that there's no need for any action, all data you have posted indicate a completely normal function until you break something, so this is now developing into a waste of time. If you can't answer the questions that have been asked multiple times now, then don't complain that nobody else follows things up here.