Re: [Flightgear-devel] Flightgear remote "modules"
Just a quick back-of-the-envelope calculation, based upon the SU-37 A/P config... 11 filters at 2 x 128 bits 21 pid controllers at 3 x 128 bits double the data length for oversight/heads = 11 x 2 x 256 = 5632 bits + 21 x 3 x 256 = 63 x 256 = 16128 bits tot 21960 bits running at the same default rate as the fdm of 120 Hz = 120 x 21960 = 2,615,600 bps This would start to challenge a 10 Mb lan, would be less of a problem on 100Mb and little problem on Gb or multi-core intra-chip comms. Are these calculations in the right ball-park? LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
Ralf Gerlich writes: > Rob Ratcliff wrote: > > You could use an event distribution (Pub/Sub) paradigm based on > > something like the CORBA Notification Service (Event Service), the > > CORBA property service, the newer Data Distribution Service > (DDS) or > > something like the High Level Architecture (HLA). A CORBA ORB TAO > > supports communication across shared memory or sockets depending on > > where the clients and services are running. I know that TAO is used > > quite a bit for real time control systems communication for > the military. > > Do you know the order of magnitude of the real time deadlines > for the subsystem where TAO has been used? ICE from zeroc is interesting http://zeroc.com/ Cheers Norman - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
On Tuesday 13 February 2007 02:21, Martin Spott wrote: > Did you already find one that matches ? > > Martin. If you want an example: Designing multimedia applications on real-time systems with SMP architecture Abstract Large real-time multimedia systems such as flight simulators have adopted multiprocessor architecture to handle the large amount of events and computations. Existing realtime scheduling algorithms designed for single-processor systems such as Rate Monotonic (RM) and Earliest Deadline First Algorithm (EDF) have very poor performance on multiprocessor systems. On the other hand, most online scheduling algorithms for multiprocessor systems have poor schedulability conditions for real-time applications. In this paper, we study different ways to design real-time applications on SMP machines. This one is interesting too: Implementation of a flight trainer simulator using a microprocessor based network: a system architecture selection report Abstract After a general introduction concerning flight simulator development problems and the goals of the study, functional and development requirements are specified and the needed computing capacity is evaluated. (The same methodology can be applied to any real-time embedded computer system.) Typical benchmarks are introduced and analytical expressions on the time spent on communication are explained for cases of common memory, Multibus II and VME. The conclusions indicate the preferred solution, why it was selected and intentions for continuation of this work in the immediate future. The methodology presented and the resulting solution provide a simple way for combining existing hardware elements to achieve a low-cost implementation. Did _you_ find any report that matches? If you did but can't access it, I can try and access it at my university. Ampere - 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
Re: [Flightgear-devel] Flightgear remote "modules"
Ralf Gerlich wrote: >Hi, > >Rob Ratcliff wrote: > > >>You could use an event distribution (Pub/Sub) paradigm based on >>something like the CORBA Notification Service (Event Service), the CORBA >>property service, the newer Data Distribution Service (DDS) or something >>like the High Level Architecture (HLA). A CORBA ORB TAO supports >>communication across shared memory or sockets depending on where the >>clients and services are running. I know that TAO is used quite a bit >>for real time control systems communication for the military. >> >> > >Do you know the order of magnitude of the real time deadlines for the >subsystem where TAO has been used? > > > See http://www.cs.wustl.edu/~schmidt/PDF/words-02.pdf for some info on subject JW - 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
Re: [Flightgear-devel] Flightgear remote "modules"
Hi Ralf, I don't know the deadlines, but I know Doug Schmidt (author of Tao) would. His email is: [EMAIL PROTECTED] Malcolm Spence (of OCI that provide commercial support to this free and open source ORB) would have a good idea as well or could find out. His email is: [EMAIL PROTECTED] There are some benchmarks of various messaging systems and ORBs available at: http://www.atl.external.lmco.com/projects/QoS (The MW_Comparator allows you to compare the performance of many of the ORBs.) There are a ton of references available at: http://www.cs.wustl.edu/~schmidt/TAO.html that might have some information useful to you. Rob Ralf Gerlich wrote: Hi, Rob Ratcliff wrote: You could use an event distribution (Pub/Sub) paradigm based on something like the CORBA Notification Service (Event Service), the CORBA property service, the newer Data Distribution Service (DDS) or something like the High Level Architecture (HLA). A CORBA ORB TAO supports communication across shared memory or sockets depending on where the clients and services are running. I know that TAO is used quite a bit for real time control systems communication for the military. Do you know the order of magnitude of the real time deadlines for the subsystem where TAO has been used? Cheers, Ralf - 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 - 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
Re: [Flightgear-devel] Flightgear remote "modules"
Hi, Rob Ratcliff wrote: > You could use an event distribution (Pub/Sub) paradigm based on > something like the CORBA Notification Service (Event Service), the CORBA > property service, the newer Data Distribution Service (DDS) or something > like the High Level Architecture (HLA). A CORBA ORB TAO supports > communication across shared memory or sockets depending on where the > clients and services are running. I know that TAO is used quite a bit > for real time control systems communication for the military. Do you know the order of magnitude of the real time deadlines for the subsystem where TAO has been used? Cheers, Ralf - 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
Re: [Flightgear-devel] Flightgear remote "modules"
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 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 ---
Re: [Flightgear-devel] Flightgear remote "modules"
Curtis Olson wrote: > > > 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. :-) > You could use an event distribution (Pub/Sub) paradigm based on something like the CORBA Notification Service (Event Service), the CORBA property service, the newer Data Distribution Service (DDS) or something like the High Level Architecture (HLA). A CORBA ORB TAO supports communication across shared memory or sockets depending on where the clients and services are running. I know that TAO is used quite a bit for real time control systems communication for the military. - 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
Re: [Flightgear-devel] Flightgear remote "modules"
"Ampere K. Hardraade" wrote: > On Monday 12 February 2007 14:10, Curtis Olson wrote: > > 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. :-) > A place where one would likely find such phd thesis is IEEE's website. Did you already find one that matches ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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
Re: [Flightgear-devel] Flightgear remote "modules"
On Monday 12 February 2007 14:10, Curtis Olson wrote: > > > 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. A place where one would likely find such phd thesis is IEEE's website. Ampere - 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
Re: [Flightgear-devel] Flightgear remote "modules"
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 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. > > > I solved that problem on the 747 sim by going to real-time linux. The open source version from DIAPM and Xeonami are just as good as the more expensive commercial stuff. Now there is a kernel-ready distribution available for linux, see http://www.mecatronica.eesc.usp.br/~aroca/slax-rt/ although installing RTAI/Xenomai from scratch and recompiling the kernel is not all that difficult. All the RT tasks now run rock solid. It has made a big difference along with a real-time hardware interrupt module in how the controller(s) function and the response of the system to external stimulii. You could possibly redo FlightGear in real-time, but you would lose portability. Regards John W. - 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
Re: [Flightgear-devel] Flightgear remote "modules"
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 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
Re: [Flightgear-devel] Flightgear remote "modules"
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 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. 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
