certi-devel
[Top][All Lists]
Advanced

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

RE: Re: [certi-dev] CERTI performance issue


From: Gotthard, Petr
Subject: RE: Re: [certi-dev] CERTI performance issue
Date: Tue, 16 Jun 2009 09:52:36 +0200

Hi Michael,

 

Are you sure the number of TICK_REQUEST messages between federate and RTIA stayed the same? I would expect the number of federate TICK requests is lower by several orders of magnitude.

 

 

Petr

 

From: address@hidden [mailto:address@hidden On Behalf Of Michael Raab
Sent: Tuesday, June 16, 2009 9:34 AM
To: CERTI development discussions
Subject: Re: Re: [certi-dev] CERTI performance issue

 


Hi all,

got the information on our internal tick usage.
Internally we've used the tick function without parameters, which resulted in the discussed performance issues.

I did a test using tick(min, max) and got a great performance boost.
Execution time went down from 1200s to 51s, while the number of sent null messages and tick requests stayed nearly the same.

Some ideas how this is possible?

If this perfomance stays the same in further tests, i think we can delay the implementation of second generation time management techniques.

Regards,
Michael



Dipl.-Inf. Michael Raab

Fraunhofer-Institut für Fabrikbetrieb und -automatisierung IFF
Virtuell Interaktives Training
Sandtorstr. 22, 39106 Magdeburg, Germany                
Telefon +49 (0) 391/ 40 90 122
Telefax +49 (0) 391/ 40 90 115
address@hidden
http://www.iff.fraunhofer.de oder http://www.vdtc.de

Eric Noulard <address@hidden>
Gesendet von: address@hidden

05/29/2009 11:18 AM

Bitte antworten an
CERTI development discussions <address@hidden>

An

CERTI development discussions <address@hidden>

Kopie

Thema

Re: [certi-dev] CERTI performance issue

 





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.

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

--
Erk


--
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel


reply via email to

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