certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] CERTI performance issue


From: Pierre Siron
Subject: Re: [certi-dev] CERTI performance issue
Date: Tue, 02 Jun 2009 15:44:37 +0200
User-agent: Thunderbird 2.0.0.18 (X11/20081120)

Eric Noulard a écrit :
I add some practical suggestion in order to
bring those "second generation" time management algorithm into CERTI.

2009/5/29 Pierre Siron <address@hidden>:
  
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).
    

We should develop a test federation (which may be added to HLA Tests Suite)
which follow this pattern. Ideally it would consists in 1 executable
which takes as many command line options as needed in order
to fullfill its role in the targeted pattern.
  
Bonjour tout le monde,
salut Eric,
during the week-end I have refreshed my memory ...

We have met this kind of problem during the SICODIS project at ONERA,
and we have written the Interactive_Federate to illustrate it
(I am still using this federate for my HLA teaching ...).
So we have already a federation test, and a use case is described in
HLA_TestsSuite/DOC/test_time_creep.odp   !!!

Obviously, during the test, we can only count the tick requests and
the Null messages. We do not have performance measurement in seconds.

Warmly,
Pierre





for example:

FedNextGenTM --fom=blah.fed --fedname="NextGenTMFederation" --name
"Fed1" --lookahead=0.5 --ner-step=10

which would launch one federate using "blah.fed" FOM file, the
federation name is "NextGenTMFederation"
the federate name is "Fed1", lookahead 0.5 and issue NER request with step 10.

Michael may be you can give us a more thorough description of your
testcase, which may
I would suggest to document the test case using some kind of MSC description
(may be incomplete but sufficient information).

I join an example using mscgen (http://www.mcternan.me.uk/mscgen/)
which present the advantage of being usable on both unix and windows
and it could be embedded in doxygen source code documentation.

try:
mscgen -T png -i HLA-TimeCreep.txt -o HLA-TimeCreep.png
  
seems a lot better than my odp

  
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).
    

[...]

No comment on this on my side now.

What I will do is to open a task on the Savannah tracker for that
"Implementing second generation time management"
(once Savannah has come back) and I invite interested people
to comment on the task tracker.

public discussion should off-course continue on the ML but it
may be easier to attach files/patch to the tracker than sending those
directly on the ML.

For people who want to contribute we (CERTI current developer)
will give support for the newcomers who wants to get knowledge of the
CERTI internals.

Do not hesitate to dive into the CERTI code and/or provide patch.

I would say that the first step would be to design and implement
the portable test federation.
In the meantime we continue to discuss the techncal solution.
Then volunteer goes on with patch for supporting the chosen solution in CERTI.


  



reply via email to

[Prev in Thread] Current Thread [Next in Thread]