|Subject:||Re: [certi-dev] CERTI performance issue|
|Date:||Fri, 29 May 2009 14:26:21 +0200|
|User-agent:||Thunderbird 22.214.171.124 (X11/20090320)|
Michael Raab a écrit :
Was it the explanation of your problem ?
Would you tell me your ideas about the second generation approach.Ok,
I can try to develop that.
What is the case that we could try to solve ?
The federation includes n federates in coordinated time,
we have n pending nextEventRequest (Ti)
and small lookaheads (Ti).
I find difficult to build a distributed snapshot of the distributed
simulation because :
- This requires a complex distributed algorithm (that we can find
in the literature) and a new amount of messages.
- This construction must be done periodically (which rhythm ?)
or asynchronously (which event ?).
We have won if a process (respectively all the processes) identifies
the situation and then causes a long jump in the time (an advance
to the min of Ti + Li).
What can help to this identification ?
To add some information to a Null message :
- This message has been provoked by TAR or TARA or NER or NERA or ...
- The Ti value.
- The sender i if this data is not yet available.
Who does receive or see the Null messages ?
- Each constrained federate receives them.
- The RTIG forwards them.
A constant idea is to avoid an overload of the RTIG.
It has enough to do in the messages routing.
How to solve the problem after the time creep identification ?
We can do that without changing in depth the RTIA, without
changing the RTIG and without introducing a new type of message
(just the Null message modification).
Each federate i sends a new Null Message with the min of Tj
(Li is then automatically added in sendNullMessage).
Consequently each federate will receive n - 1 Null messages
of the peers and will do the expected jump.
Your advice ?
Est-ce correct ?
PS: the case of a mixture of TAR and NER could also
|[Prev in Thread]||Current Thread||[Next in Thread]|