Re: [certi-dev] CERTI performance issue

[Pierre Siron]

Michael Raab a écrit :

Hello,

Bonjour,

thank your for explanations and the nice tutorial.

Was it the explanation of your problem ?

So i  guess CERTI is using the NullMessage approach.

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.