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. LeeE ------------------------------------------------------------------------- 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
