On 2/12/07, leee wrote:

On Monday 12 February 2007 17:54, Jim Campbell wrote:
> Hi,
> Curtis has already hinted as to how the following may be done with his
> "remote" FDM.
> To my mind flightgear can be broken down into distinct plugin
> "modules". There is the FDM, the "external world" visualisation,the
> cockpit input and output (ie joystick,pedals,switches and displays) and
> possibly a motion system. These can be interconnected with some inter
> process communication scheme. All of the modules could be run on a SMP
> hardware (e.g dual dual-core cpus) or on separate computers. There has
> been some discussion on multi-threading which would handle the first
> (via shared memory IPC perhaps) but without an operating system that
> can migrate threads to other networked processors then I think a more
> flexible approach may be "self-contained" modules communicating by
> passing "properties" over TCP. The "remote" FDM is already a
> possibility and there is an example of a remote joystick but how easy
> would it be to break up the rest of flightgear? Any ideas anyone?
> cheers
> Jim

I too think that this would be the best approach for making FG MPP
compatible.

The greatest cpu hog, so I believe, is the graphics subsystem but even
though
the other subsystems don't require as much processing power they are still
limited in the resources they get.  For example, while I was doing a
couple
of tests for what appears to be an A/P problem I noticed that the rate of
the
controllers were varying even though I'd specified a <Ts> period.  This is
certainly going to result in some unpredictable behaviour across different
systems and I wouldn't be surprised if some of the other subsystems are
equally limited in their rates.



This is all very interesting stuff to think about and discuss, but it's also
very difficult stuff too.  As soon as you start splitting out modules into
separate processes/threads/cpu's, timing issues start becoming very
critical.  Often times, things that are very simple and straightforward to
implement in a single thread, become extremely difficult and cantankerous
when trying to move to distributed architecture.

As Lee points out, the limiting factor is the graphics rendering which used
to take upwards of 90-95% of the work load last time I did some profiling.

The AP timing is a problem ... but that's more a side effect of too many
cooks in the stew I think.  At one point I had setup the AP to run along
with the FDM loop so the two were tied together and ran at the same update
rate with the same dt.  That was changed (and I think was changed a long
time ago) so the AP runs at graphics update rates ... as you point out,
these are not necessarily consistant and will definitely change across
different installations.  But this particular problem is fixable within the
current context of FlightGear.

Personally, I think the most sane approach with the highest chance of
succeeding will be to pick some particular submodule that really makes sense
to run on another machine or in a separate process and figure out how to
split that off.

Otherwise you are probably going to be wrestling with a complete
reachitecting of the entire FlightGear structure.  Things like the property
system work great in a single thread application, but start to break down
when you split modules off into separate computers ... how do you
effeciently and robustly replicate the property system across a distributed
set of PC's, especially if you want any remote module to be able to change
any property at any time?  Might be a fun project for someone's phd thesis
if they are specializing in distributed systems. :-)

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to