Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Richard » Sat Dec 19, 2015 9:05 pm

A private tree isn't going to help us; and any encapsulation needs to be considered properly. The HUD already uses a data provider to avoid having to access the property tree twice for the two panes.

I think it's pretty efficient the way it's structured even using sprintf as there aren't going to be that many wasted cycles even with the multi display as only one display will be updated per timer frame (10hz) which means the effective update rate per display is 1hz.

This sort of load is going to be a drop in the ocean compared to the geometry and FDM.

I'd need to see evidence of a real performance impact of the MDU Nasal/Canvas code that we have before it gets changed.
Richard
 
Posts: 708
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 9:21 pm

Right, like Thorsten said: 500+ property updates (polling) would surely show up - especially given that a few years ago, that was pretty much the load caused by the whole simulator per frame. So it will be interesting to see if/how the complexity of these instruments is adding up (or not).

But all the sprintf/getprop-level overhead that is accumulating through update() loops invoked via timers would be straightforward to reduce significantly (or even eliminate) by extending CanvasElement/CanvasText so that it supports labels in the form of sprintf format strings that are populated by using a property node (sub-tree), which would mean that there would be zero Nasal overhead for those labels/nodes that can be expressed using static format strings and a fixed set of dynamic properties.

All the polling could be prevented then, and updating would be moved to C++ space.

We ended up using a similar approach when we noticed that drawing taxiway layers would create remarkable property overhead, so that we troubleshooted the whole thing, at which point, TheTom added helpers to further reduce system/Nasal load

sanhozay wrote in Sat Dec 19, 2015 8:59 pm:What are the rules for thread safety when reading/writing the property tree from multiple threads in Nasal?

FlightGear's main loop is primarily single-threaded, most of its subsystems were not added/maintained with thread-safety in mind.
Nasal is in fact the only component intended to be threadsafe - however, that does not apply to the FlightGear integration layer (extension functions/APIs).
Thus, you are in uncharted waters basically

Which is to say that you generally want to avoid using threads and only consider them a tool for exploring alternate solutions.
However, worker threads can access arbitrary Nasal data structures using the threads module and its helpers for synchronization.

So you would be "safe" to do background processing using worker threads, e.g. for calculations - as long as you don't access any FG specific extension functions, which includes timers, listeners etc
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby AndersG » Sat Dec 19, 2015 9:51 pm

sanhozay wrote in Sat Dec 19, 2015 8:59 pm:What are the rules for thread safety when reading/writing the property tree from multiple threads in Nasal?


As Hooray said above, but shorter: The rule is DO NOT.
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2442
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 10:01 pm

"The property tree" is the global property tree, which you simply cannot access in any threadsafe way currently.
Next, there is "the property tree code" of which you can create separate instances (objects), even from Nasal.

The example I posted is using such a private property tree object to write/read properties, but only from the worker thread - it will never be accessed from other threads, and will in fact seize to exist once the callback terminates (it will be GC'ed).

Whether that works or not, depends not only on the way you are using such a "private" property tree - because not even the code itself has been designed with thread-safety in mind.

In other words, problematic code (think static variables, e.g. a counter/ref) may still cause race conditions, even if the private property tree is never written two from separate threads.

Apart from that, even such Nasal worker threads will be affect the main loop in the sense that the main loop will need to stop to run the global GC scheme, which is not thread-specific.

So if you do want to use worker threads in Nasal, you would want to only use it for certain calculations, i.e. in the form of worker threads - while also making the whole thing entirely optional, because -unlike Nasal- much/most of FlightGear was not designed/maintained with thread-safety in mind, which also includes some of the most recent additions.

At some point, it might be interesting to explore having separate Nasal interpreters for different purposes (think GUI vs. aircraft vs. scenery scripts) running concurrently, to ensure that there are separate subsystems running, which may not interfere with each other.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 11:15 pm

Richard wrote in Sat Dec 19, 2015 9:05 pm:I'd need to see evidence of a real performance impact of the MDU Nasal/Canvas code that we have before it gets changed.


FWIW: You can wrap your update calls (via settimer() or maketimer() using debug.benchmark() (see debug.nas) - the first argument is an identifier (string), the 2nd is the callback to be invoked, if you need to pass any arguments, wrap the whole thing in a closure by prepending a func

Depending on the structure of your MFD framework, you may get away with only doing this in a single place, and letting virtual dispatch handle the details of each page.update() call, while still getting detailed timing info for each update call (via systime)
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sun Dec 20, 2015 6:29 am

A private property tree doesn't help, because most displays are to show systems parameters and the system simulation runs in JSBSim.

In the early stages of AW (i.e. before Stuart developed an API to draw clouds from Nasal) I did manage clouds via massive property tree access. Back then (that's perhaps five years and two computers ago) I ran into trouble reading, updating and writing the state of 500+ clouds per frame (that's 1500 accesses). I then re-structured the code that the master copy of the state is a Nasal vector, so I only had to do property access to update, essentially reducing the load to 500 accesses. That turned out to be feasible (two computer generations ago). I believe that these days not only computers are faster, but also property access is slightly more efficient, so FG should tolerate somewhat more, but not infinity.

I think Richard asked the relevant question:

If you run the Shuttle in-cockpit on a low performance machine, the framerate sucks.

But is this

a) because the cockpit mesh is really heavy to render
b) because the many JSBSim systems drag performance
c) because the canvas/avionics drags performance

I have limited hardware options to test, but from what I've seen here and at FSWeekend on Durk's machine I'm going with a). Richard's test data posted above also indicates a) as main culprit, followed by b).

So while the display structure may not be optimized, it's not clear to me whether it is actually a serious issue in the whole picture and whether we shouldn't optimize something else first. Even with many different displays open, I have not been able to see a serious impact even on lower-powered hardware.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby wlbragg » Sun Dec 20, 2015 9:02 am

One of the CPU's I'm working on is a 4gig Linux box that can barely handle the Shuttle. I can honestly say that recently the performance hasn't changed enough to be noticeable. The addition of all the MDU's really had no effect on an already under powered machine, at least not one I could notice and I think if any one would notice it, it would be on an already hard pressed CPU.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4890
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Space Shuttle

Postby Hooray » Sun Dec 20, 2015 9:30 am

interestingly, we are not seeing the whole "being CPU vs. GPU limited" debate here :D

Anyway, there is support for tracing READ/WRITE accesses: http://api-docs.freeflightsim.org/simge ... yNode.html

I haven't checked if the setAttribute() stuff is exposed to Nasal currently.

But the tracing code could be adapted to update a counter (property) instead of logging to the console: http://api-docs.freeflightsim.org/simge ... c9c5aa767e
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sun Dec 20, 2015 11:19 am

interestingly, we are not seeing the whole "being CPU vs. GPU limited" debate here


Maybe you missed that part? Richard on low-powered HW is clearly GPU limited, and so am I on the old machine, with the choke point being the detailed mesh of the cockpit interior.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Sun Dec 20, 2015 3:07 pm

After thinking this through, I suggest to do it as follows: Given the requirements we have with fetching properties and displaying them (some of them need to be just formated, others need to be go through unit conversion, yet others need to be changed into a string dependent on value, yet others get some value added,...) it's not straightforward to generalize all of this without passing pointers to functions (do we even have these in Nasal?)

As we don't have an alternative right now, I see no benefit in taking action right now - should there be a future canvas operation doing the same which is demonstrably faster, I'll go and replace what we have then.

I will do some more performance testing, but honestly, I expected the multiple MDUs to be much worse than they actually are, and it really seems they're not the main issue.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sun Dec 20, 2015 3:36 pm

you can treat function objects like "pointers" in Nasal.

I agree with your plan though - however, it will suffice to just wrap such functionality using a helper function, and then update that as/if needed.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Hooray » Sun Dec 20, 2015 7:43 pm

For the record, the screen shots recently uploaded on the wiki, are increasingly looking like the screen shots from: https://en.wikipedia.org/wiki/Space_Shu ... ssion_2007

Space Shuttle Mission 2007, also SSM2007 is a highly realistic Space Shuttle stand-alone mission simulator for the Microsoft Windows operating system. The simulator was released on January 1, 2008 after having been under development for more than six years.

Space Shuttle Mission 2007 has been developed by a team of space exploration enthusiasts whose idea was to bring the old and venerable Virgin Shuttle Simulator alive again and match the new PC technology by re-designing a new Space Shuttle simulator from the ground up and adding better graphics and more features. The team planned to develop Space Shuttle Mission 2007 as a freeware game, but as the project became more ambitious and significant resources had to be invested to meet the new design requirements, the team decided to release the simulator as a commercial indie project.

http://wiki.ssm-fans.info/ops2
Image


given that this thread started out in March 2015, that's quite a feat in and of itself already ! :D
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby jonsberndt » Mon Dec 21, 2015 4:09 am

Thorsten wrote in Sun Dec 20, 2015 6:29 am:
If you run the Shuttle in-cockpit on a low performance machine, the framerate sucks.

But is this

a) because the cockpit mesh is really heavy to render
b) because the many JSBSim systems drag performance
c) because the canvas/avionics drags performance

I have limited hardware options to test, but from what I've seen here and at FSWeekend on Durk's machine I'm going with a). Richard's test data posted above also indicates a) as main culprit, followed by b).


Interesting thread. I'll add here that JSBSim <systems> could, theoretically, be a performance concern if the systems are huge. I developed and executed some basic (but complex) GNC algorithms with little problem, though, a couple of years ago. That included also a massive aerodynamic database. I suppose I might try to download the shuttle model at some point. Will it run in JSBSim standalone? I'd be interested to take a look at the systems design. It would be an option to turn certain channels off when they are not being used.

Jon
Jon S. Berndt
Development Coordinator
JSBSim Project
http://www.JSBSim.org
http://www.facebook.com/jsbsim
User avatar
jonsberndt
 
Posts: 205
Joined: Tue Aug 07, 2007 1:44 am
Location: Westminster, Colorado

Re: Space Shuttle

Postby Thorsten » Mon Dec 21, 2015 6:23 am

Will it run in JSBSim standalone?


My educated guess is not if you don't switch off some channels - I remember there's FG-native properties referenced by JSBSIm systems in several places.

Also, the higher-level planning tasks (automatic OMS burn duration and attitude, entry and TAEM guidance, ...), the thermal computations (radiation balance, heat transfer, freon loop operations,...) and the CWS are done by Nasal as they don't need to be computed at FDM rate (and sometimes need to be computed just once).

The basic aerodynamics simulation and the FCS however should run fine.

Space Shuttle Mission 2007, also SSM2007 is a highly realistic Space Shuttle stand-alone mission simulator for the Microsoft Windows operating system.


:-)

That's actually not the original antenna pointing screen - the list of TDRS state vectors and line-of-sight info is missing... There's also the Orbiter Space Shuttle Ultra project.

Though we do have several advantages - first, JSBSim and large aero databases from NASA combine into realistic flight and orbital dynamics quickly. Second, the way canvas allows screens by compositing elements means rapid advancement - I don't have all common elements to all screens going for instance, but it's a piece of cake just adding something to the common section.

Well, at the end of the day, we have a really large toolkit to get things done - JSBSim tags, property rules, Nasal, configurable effects and shaders,... so lots of things can be done rapdily without the need to learn how to code it in detail.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Richard » Mon Dec 21, 2015 10:33 am

jonsberndt wrote in Mon Dec 21, 2015 4:09 am:Interesting thread. I'll add here that JSBSim <systems> could, theoretically, be a performance concern if the systems are huge. I


I don't see the JSBSim as being an overall performance hog compared to the mesh. When I made the tests my laptop was running in Battery Saving Mode - which reduces the i7 264M clock down to 0.76GHz (usually 3.3GHz) - and with the FDM running at 120hz this left not very much CPU for anything else. If I reduce to 60hz then it gets better.

I am working on a change which adds a rate to the system definition. Not everything needs to run at full rate and it is only the developer of the system that will know this. The design is quite simple, the rate is 1 for every frame, 2 for every other frame; etc. i.e. what is usually called half rate, quarter rate.

so you'd do something like

Code: Select all
<system name="Electrics" rate="4">
Richard
 
Posts: 708
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 4 guests