Re: [certi-dev] CERTI performance issue

[Pierre Siron]

Eric Noulard a écrit :
> 2009/5/29 Michael Raab <address@hidden>:
>   
>> Dear all,
>>
>> some more information from our side:
>>
>>     
>>> How long does this simulation run (elapse time)?
>>>       
>> approx. 1200 s
>>
>>     
>>>  3 federates: are they all tree time regulating and time constrained?
>>>       
>> Yes!
>>
>>     
>>>  Elapsed (Wall Clock) Time :
>>>       
>> What do you mean? We have no real time application like a flight simulator.
>> We're using CERTI to connect some discrete event simulation systems,
>> in this case three instances of SLX ( FYI http://www.wolverinesoftware.com/
>> ).
>>     
>
> Elapse Time you may read on the Wall Clock during your simulation run.
> That's  your 1200s.
>
> That said, you have something like 158687 NULL message sent fro Fed2
> which makes 158687/1200 =  132+ message per second.
> This is really too much NULL messages.
>
> However this may be due to the time creep problem, I let Pierre
> explain that for us.
>   
Hello,
thank you for this task Eric,
the time creep problem is well illustrated in this tutorial of Richard
Fujimoto :
"Parallel & Distributed Simulation Systems : From Chandy/Misra to the
High Level Architecture and Beyond"
and in his books.

The first generation of time management algorithms suffers of this problem.
If the lookahead is small with regards to the time step of the
nextEventRequest,
a round of NULL messages (and ticks) is required before the
timeAdvanceGrant.
This is probably your case.

For a good efficiency, the lookahead should be as great as possible.

In the second generation, a global LBTS is computed after a global
snapshot of the distributed simulation (which requires other messages).
We have some ideas to add that in CERTI  and  I did not khnow what
the RTI NG has implemented.

Au revoir,
Pierre



> In the same way 85253/1200 = 71+ tick request per second, this is sustainable
> but seems exagerate.
>
>   
>>>  We lack some network topology figures, do each federate run
>>>       
> [...]
>   
>> All three federates plus the rtig run on a single machine, which has 4 cores
>> ( 2 opterons ) and is connected to 100Mb/s network.
>>     
>
> Then all thoses federates may be ping-ponging themselves the
> processing ressources.
> With 3 federates plus rtig you have  7 processes (3 federates + 3 RTIA
> + 1 RTIG).
> Is the average load of the machine high during the run or not?
>
>   
>>> Would you be able to update an rerun in order to see if recently fixed bug
>>> http://savannah.nongnu.org/bugs/?26610 improves this situation.
>>>       
>> Can't check as savannah is down. I'm using the cvs checkout from yesterday.
>> Was this bugfix included?
>>     
>
> Depends on the date of your update :-)
> I will seek the date and send you the correspondinfg file.
>
> Concerning Savannah outage sysadmin told us we cannot expect
> restore until 24h.
>
> "
> Savannah experienced a filesystem corruption and is now halted.
>
> The mailing lists and webpages are not affected by the outage.
> The website, CVS/SVN/Git/Hg/Bzr, and the download area are affected."
>
>   
>>> Which version of tick are you using in your federate?
>>>       
>> Can't tell you at this moment as this is encapsulated in a wrapper dll, for
>> which i don't have the source. I will ask a partner later today.
>>     
>
> Ok that would be good to know.
>
>   
>>> If your source code may be shared I may try to run the very same setup
>>> on a Linux config in order to see if I get similar figures.
>>>       
>> Btw, unfortunatly i'm not able to share the source and the SLX simulation
>> system is windows only.
>>     
>
> Such a shame :-)
>
>