Re: [certi-dev] Question about NextEventRequest Service

[Eric Noulard]

2010/10/29 Roth, Christoph <address@hidden>:
> Hi,

Hi Christoph,

> I have got a question concerning synchronization. My scenario is the
> following:
>
> I have two federates f1 and f2. Both are event based and use the
> NextEventRequest (NERQ) Service to advance time. The simulation loop in both
> federates looks like this:
>
> ...
>
> rtiAmb->updateAttributeValues();
>
> rtiAmb->nextEventRequest(newTime);
>
> while(isAdvancing) {
>
>                 rtiAmb->tick2();
>
> }
>
> …
>
> Both federates have a lookahead of 10. Assume both federates are at the same
> time (=0). Now, if both federates request for the same new time with very
> high value like newTime=1000000 the tick2()-call lasts very long (several
> seconds) until the simulation proceeds. Have you any idea about the reason
> for this long delay? It seems as if the delay depends on the low lookahead,
> because if I increase the lookahead up to the newTime value simulation is
> much faster.
>
> In my opinion the low lookahead should have no influence on execution speed
> since both federates guarantee to not send any message with a lower
> timestamp than newTime+lookahead,

This is not entirely true....the federate ensure not to generate a
message with a time
stamp less than or equal to THE TIME OF THE GRANT (TAG message).

"If it does receive any TSO messages before the Time Advance Grant †
invocation, the joined federate shall
guarantee that it will not generate a TSO message at any point in the
future with a time stamp less than or
equal to the logical time of the grant (or less than the logical time
of the grant plus its actual lookahead if its
lookahead is not zero)."

When you request NMR you may receive from others an Interaction or UAV etc...
which generate a TAG with a timestamp [strictly] lower than the one
you passed to NERQ / NMR

> so the simulation should be able to
> directly advance (This is what I could read in the IEEE 1516.1.2000 standard
> page139), or did I make a misstake?

You should read on page 140 too :-]
With that remark on page 140 and knowing that the time management algorithm
is the Chandy-Misra-Briant (CMB) Null message algorithm (fully
distributed algorithm)
Each federate cannot ensure to other better than currentTime + Looahead
when using NMR service (this is not the same story with TAR).

The assumption you make implicitely supposed federate has "global" knowledge
of the time, which is not true with CMB.

> -          Certi 3.4.0

Bleeding edge good :-]
Since you are running CVS you may try an experimental feature of CERTI
which should enhance your particular stituation.

This feature is an ALPHA feature (use at your own risk) which is
neat modification of NULL message algorithm called
"NULL primer message algorithm" main authors
being Pierre SIRON and myself.

You can try it by defining the CMake option
CERTI_USE_NULL_PRIME_MESSAGE_PROTOCOL
to ON.

(Use cmake-gui or command line -D argument)

Normally this algorithm should do just what you expect:
bump in the nearest future for both your federate doing NMR.



-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org