27
edits
FlightGear high-level architecture support: Difference between revisions
Jump to navigation
Jump to search
FlightGear high-level architecture support (view source)
Revision as of 05:49, 3 August 2014
, 3 August 2014no edit summary
Chriscalef (talk | contribs) No edit summary |
Chriscalef (talk | contribs) No edit summary |
||
| Line 122: | Line 122: | ||
== HLA vs. Shared Memory/IPC == | == HLA vs. Shared Memory/IPC == | ||
The nice thing is that the ipc is hidden behind something that is also able to distribute this across multiple machines. A local network connect is mostly sufficient. But doing the same by an infniband connect is possible too. Experimenting with shared memory did not bring notable | The nice thing is that the ipc is hidden behind something that is also able to distribute this across multiple machines. A local network connect is mostly sufficient. But doing the same by an infniband connect is possible too. Experimenting with shared memory did not bring notable improvements over a system local network connect. At least not on linux... | ||
In any case I think this could be fast enough to do this stuff. | In any case I think this could be fast enough to do this stuff. | ||
| Line 131: | Line 131: | ||
way that you can still program your local component in a single threaded way. The coupling of components *can* be that tight so that you can get deterministic time slicing for some of the components. Say you want to simulate glider towing you can do that with each fdm running in its own process while still deterministically exchanging simulation results at a the fdm's rate and st time step boundaries. | way that you can still program your local component in a single threaded way. The coupling of components *can* be that tight so that you can get deterministic time slicing for some of the components. Say you want to simulate glider towing you can do that with each fdm running in its own process while still deterministically exchanging simulation results at a the fdm's rate and st time step boundaries. | ||
The same goes for components within the aircraft which I consider a possible use case for your kind of application. | The same goes for components within the aircraft which I consider a possible use case for your kind of application. | ||
In contrast to that, You can still run the viewers asynchronously to the | In contrast to that, You can still run the viewers asynchronously to the simulation core providing hopefully 60 stable frames without being disturbed | ||
by | by synchronization needs of specific components. | ||
So, you might have an Idea how to to that by ipc directly, and trust me I have considered this at some time. But what this | So, you might have an Idea how to to that by ipc directly, and trust me I have considered this at some time. But what this standard provides is really | ||
driven by exactly those problems that need to be solved once you dig into such kind of implementation. So one of the benefits is that you gain a encapsulated communication library that does what you need. This library can be tested independently of such an application beast like flightgear. And this is IMO a huge benefit. | driven by exactly those problems that need to be solved once you dig into such kind of implementation. So one of the benefits is that you gain a encapsulated communication library that does what you need. This library can be tested independently of such an application beast like flightgear. And this is IMO a huge benefit. | ||
== Benefits == | == Benefits == | ||
the RTI c++ interface is defined in a way that you do not need to recompile anything. | the RTI c++ interface is defined in a way that you do not need to recompile anything. Everything is done with pure virtual classes and factories to get them. So however this is implemented in the shared object/dll you should just need to get a 'standard' implementation dependent RTI header and compile with that. So you should in theory be able to change the RTI library of an already compiled binary. For the case that a particular RTI implementation does not follow this rule, you need to compile flightgear explicitly for this particular library. | ||
The spatial indices implemented in the RTI regions will be a huge benefit, since you will only | The spatial indices implemented in the RTI regions will be a huge benefit, since you will only receive the messages that are relevant near the region of your interest. | ||
Also the way an RTI provides time management and time stamped messages, is | Also the way an RTI provides time management and time stamped messages, is beneficial. This enables hard synchronized HLA federates, exchanging data at relatively high rates with the least possible communication latency. | ||
Regarding the ongoing threading discussion and the amount of cores an average cpu has today, an RTI will provide a way to implement components of the simulation in a single threaded way, living in its own process. | Regarding the ongoing threading discussion and the amount of cores an average cpu has today, an RTI will provide a way to implement components of the simulation in a single threaded way, living in its own process. | ||
| Line 151: | Line 151: | ||
Major benefits would be to move some code, such as the [[Decoupling the AI Traffic System|AI code out of the main loop]] - may be even | Major benefits would be to move some code, such as the [[Decoupling the AI Traffic System|AI code out of the main loop]] - may be even | ||
into a | into a separate process/thread. Also running one instance of that [[Decoupling the AI Traffic System|AI traffic]] for installations like we used to have at the linux tag booth would be a major advantage there. | ||
Anyway, I also consider an RTI a possible multiplayer replacement. Even if we would handle local RTI federations different than internet wide stuff. But yes, an RTI provides almost all we would need to get that right. | Anyway, I also consider an RTI a possible multiplayer replacement. Even if we would handle local RTI federations different than internet wide stuff. But yes, an RTI provides almost all we would need to get that right. | ||
What is to be | What is to be committed is in this step is an alternative to the multiplayer protocol which does not cover really all what the multiplayer protocol can do today. But there is a proof of concept and some playground to start with. | ||
The current implementation in flightgear is flexible enough to adapt to the needs of very different simulation systems. The default object model that you get is adapted to the needs of flightgear, but the implementation is | The current implementation in flightgear is flexible enough to adapt to the needs of very different simulation systems. The default object model that you get is adapted to the needs of flightgear, but the implementation is | ||
flexible enough to change the object model to the AviationSim object model for example at startup time. | flexible enough to change the object model to the AviationSim object model for example at startup time. | ||
So, this should not only provide a way to distribute | So, this should not only provide a way to distribute flightgear's simulation systems across cpus or maybe machines, this should also provide a way to increase connectivity of flightgear to other simulation systems. | ||
Also included is an RTI variant abstraction layer inside simgear to help with some common tasks that are often needed in an HLA/RTI implementation. One of the design goals of this layer was to provide a framework where | Also included is an RTI variant abstraction layer inside simgear to help with some common tasks that are often needed in an HLA/RTI implementation. One of the design goals of this layer was to provide a framework where | ||
| Line 166: | Line 166: | ||
In particular, this means that indies (fast mappings) are used wherever possible and allocations are minimized. | In particular, this means that indies (fast mappings) are used wherever possible and allocations are minimized. | ||
Currently the only implemented RTI variant is the old nonstandard HLA-1.3 api, which was the only api I had available from an open source project at the time I began with that work. But it should be | Currently the only implemented RTI variant is the old nonstandard HLA-1.3 api, which was the only api I had available from an open source project at the time I began with that work. But it should be straightforward to extend that to the two IEEE standard RTI variants. | ||
I personally think that there are still too much opportunities to break stuff. Well, with break I do not mean that it does not run or compile. With break I mean that people just put something together that works either for their private needs and they do not care further, or break in the sense that if you would know the bigger picture it would already be very clear that this cannot scale for the kind of use that will most probably happen in the not so distant future. | I personally think that there are still too much opportunities to break stuff. Well, with break I do not mean that it does not run or compile. With break I mean that people just put something together that works either for their private needs and they do not care further, or break in the sense that if you would know the bigger picture it would already be very clear that this cannot scale for the kind of use that will most probably happen in the not so distant future. | ||
| Line 174: | Line 174: | ||
Getting back to components: Latencies are a critical part of running in multiple threads/applications. This is not a particular problem of hla, this | Getting back to components: Latencies are a critical part of running in multiple threads/applications. This is not a particular problem of hla, this | ||
is a generic problem when running real time applications in parallel. I know a lot of really smart people who can even understand complex environments very well, but have no clue about the problems introduced by round trips. Seen this, this is the reason why I started that hla stuff, since this provides a framework which supports and even encourages a programming model that is able to hide latencies as good as possible. Anyway, there is a chance that you even use this api in a way that really hurts in this corner. And this is actually the really bad thing I want to avoid: If you are the first component that does not get that right you might just notice little to nothing - especially if you are running on | is a generic problem when running real time applications in parallel. I know a lot of really smart people who can even understand complex environments very well, but have no clue about the problems introduced by round trips. Seen this, this is the reason why I started that hla stuff, since this provides a framework which supports and even encourages a programming model that is able to hide latencies as good as possible. Anyway, there is a chance that you even use this api in a way that really hurts in this corner. And this is actually the really bad thing I want to avoid: If you are the first component that does not get that right you might just notice little to nothing - especially if you are running on extremely fast hardware. But when the next kind of problem is introduced this really starts to hurt more and more. And most people do not have any chance to see what happens and why. | ||
= Use Cases = | = Use Cases = | ||
== Weather Simulation == | == Weather Simulation == | ||
We can have a completely independent weather module using the HLA stuff that runs in an own process/thread. So, at that time you might be able to do more sophisticated stuff. May be it will then be possible to do a full cfd for subparts of the scene. That might be a good thing for a glider scene where you might want to have a more detailed fluid | We can have a completely independent weather module using the HLA stuff that runs in an own process/thread. So, at that time you might be able to do more sophisticated stuff. May be it will then be possible to do a full cfd for subparts of the scene. That might be a good thing for a glider scene where you might want to have a more detailed fluid behavior ... | ||
A weather module running in a different process/thread/machine that computes positions for clouds that are | A weather module running in a different process/thread/machine that computes positions for clouds that are consistently displayed on each attached viewer. | ||
That being a module that is | That being a module that is exchangeable. The simple version just interpolates metars like today, but more sophisticated versions might do a local weather | ||
simulation to get good results for thermals in some small area. The same goes for every component you can think of splitting out. | simulation to get good results for thermals in some small area. The same goes for every component you can think of splitting out. | ||
== AI Traffic == | == AI Traffic == | ||
A simple [[Decoupling the AI Traffic System|AI model]] does just the trick what it does today. But more sophisticated modules might contain an own fdm so that these machines really live in the same fluid that the weather module provides data for.Note that the RTI API already provides a | A simple [[Decoupling the AI Traffic System|AI model]] does just the trick what it does today. But more sophisticated modules might contain an own fdm so that these machines really live in the same fluid that the weather module provides data for.Note that the RTI API already provides a subscriber model that ensures that you don't feed data to participants that don't need that.May ba a radar controller screen that can be attached there to see the machines in this word. But sure that radar screen is not interested in flap animations for the aircraft ... | ||