|
From: | Pierre Siron |
Subject: | Re: [certi-dev] CERTI performance issue |
Date: | Fri, 29 May 2009 14:26:21 +0200 |
User-agent: | Thunderbird 2.0.0.21 (X11/20090320) |
Michael Raab a écrit :
Bonjour, Was it the explanation of your problem ? Yes 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 ? Bon golf, Pierre PS: the case of a mixture of TAR and NER could also be treated. |
[Prev in Thread] | Current Thread | [Next in Thread] |