Aaaaah! I have a plausible explanation: You do nextEventRequest()
and then immediately check for the grant, which did not arrive yet. Then you
wait 1s and check again. Although the grant doesn’t arrive immediately,
it arrives very soon. But you always wait for 1s before the second tick(). The
second tick() always succeeds.
To prove my theory, you can use usleep(0.5 * 1000000) instead of
sleep(1). This will wait only 0.5s. If I’m right, the performance will
improve, but the TICK count stays the same.
Petr
From:
address@hidden
[mailto:address@hidden On
Behalf Of Michael Raab
Sent: Tuesday, June 16, 2009 11:21 AM
To: CERTI development discussions
Subject: Re: RE: RE: Re: [certi-dev] CERTI performance issue
Sorry, i don't
have the code here, but a fellow told me that it looks like this:
nextEventRequest(
... )
while( true )
{
tick();
if( grantArrived )
break;
sleep(1);
}
regards,
Michael
|
"Gotthard,
Petr" <address@hidden>
Gesendet von:
address@hidden
06/16/2009
11:17 AM
|
Bitte antworten an
CERTI development discussions <address@hidden>
|
|
|
An
|
"CERTI
development discussions" <address@hidden>
|
|
Kopie
|
|
|
Thema
|
RE:
RE: Re: [certi-dev] CERTI performance issue
|
|
I
verified that the RTIA statistics are correct.
In
a plain while(1) tick() loop I get about 50000 TICK_REQUEST per second. This
explains the extremely bad performance when using such plain loop, but does not
explain the performance boost in your case.
Do
you use the plain tick() loop, or a more sophisticated tick-ing scheme?
Petr
From:
address@hidden
[mailto:address@hidden On
Behalf Of Michael Raab
Sent: Tuesday, June 16, 2009 10:18 AM
To: CERTI development discussions
Subject: Re: RE: Re: [certi-dev] CERTI performance issue
If the rtia message statistics are correct, than there's no significant
difference...
Michael
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
--
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel