On Monday 12 February 2007 19:10, Curtis Olson wrote:
> 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.

I agree that the approach you suggest, of starting with a single 
subsystem/module is probably the best way to start tackling this issue.

I think that there are two aspects to this issue - performance and mpp 
capability - perhaps they could be viewed as two sides of a single 'coin'.

Ultimately, mpp is inevitable because it is the only realistic way of 
achieving potentially un-limited processing power and we are seeing the 
general acceptance of this principle with the current generation of 
multi-core x86 processors.  Even these, however, are only a relatively early 
step in that direction and I think that the arrival of the cell processor 
represents the next step after that.

As the hardware continues to develop in this direction high-performance 
software has to follow it if it's not to be left behind.

Although FG doesn't need to be mpp capable right now, in a few years it will 
and now is probably a good time to start thinking about it if a _good_ 
solution is to be found by the time that it's needed.


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
Flightgear-devel mailing list

Reply via email to