Multicore Processing and Clusters

These are personal musings at this point. I'm just trying to figure out what needs to be thought about to implement flightgear on multiple cores or on a cluster. This is not a project.

All this is highly speculative on my part. I've never done any work like this.

We could talk about some things that might be done

• Cleanup of existing code
• Replacement of an individual library
• Addition of unit and system tests (alredy in play)
• Restructuring subsystems and code to support multiprocessing or clusters
• A Bottom up Rewrite
• A Top to Bottom Rewrite

How does one re-architect Flighgear without disruptive effects:

- distracting developers from the projects they've already undertaken - discouraging the wider community of Scenery and Aircraft developers

Answer: Small steps: Do it like Edward's done recently with the test suite and subsystem work. Thats the existing flighgear development model and it works.

What processor or cluster architectures would you like to support? Why?

   o single system psu, motherboard, os, multi-core processor
   o multi system (cluster) 
     - ethernet connected
     - USB connected 
   o multi-os, multi system cluster, 

- desktop on one, rtos on another

multiple processors? How many, 2, 4, 6, 8, however many you have?

What language or library would you use write the process control mechanism? Is C++ one of the better choices? Which library? Why not more than one?

How will the processes communicate at the software and hardware levels?

   o Ethernet 
   o USB 
   o inter-process communication

How will this communication be prioritized How will the processing of communications be prioritized within a subsystem. How will you avoid or mitigate communication congestion?

Will there be one or more flight simulator specific communication protocols.

How fast will different parts need to communicate with each other?

What would you LIKE to separate into independent processes and what would that mean in terms of communication between the processes.

Not a definitive list:

   o Terrain features
   o Terrain avoidance
   o Rendering
     --Terrain
     --Aircraft
     --Traffic
   o Flight dynamics model
   o Engine
   o Propeller
   o Propulsion
   o Controls
   o Instruments
   o Radios
   o Navigational Aids
   o Audio
   o Multiplayer
   o AI
   and so forth

   o aggregate property tree (would we even need one?)
     Does the FDM need to know what frequency Com1 is tuned to?
     probably not.
     Does the FDM need to know we are close to landing?  Probably.

How would you group these together? Could each be a separate process? Where's the line between reasonable number of processes and communication congestion? What do each of the processes need at startup, how can they particpate in a reset,