Re: [certi-dev] Speed of attributes updates beetwen two federates with time managenment enabled

[Eric Noulard]

2009/4/10 Gotthard, Petr <address@hidden>:
> Hi Max,
>

> Besides the byte counters you sent, each federate (RTIA) should at the end
> print “RTIA: Statistics (processed messages)”. This list shows number of
> messages sent/received by RTIA. One of the lines is Message::TICK_REQUEST.
> These numbers should have reasonable values, none should be extremely high.

Those statistics are shown on federate/RTIA side not on RTIG side.


> I don’t recommend using the parameter-less non-blocking tick() function.
> Especially when used in the main loop the tick() generates extreme overhead.
> Each tick() invocation generates one TICK_REQUEST message.
>
> If you just wait for a federate service (callback) invocation, you may want
> to use the tick(p1, p2) function. The function will wait for a callback for
> p1 seconds and then invokes one or more incoming callbacks, for up to p2
> seconds. If you do nothing but tick-ing, there is no need for the tick() to
> finish and restart again. You may thus even use
> std::numeric_limits<double>::infinity() as p1 and p2. In that case the
> tick() will be blocked until some callback comes, so the tick-ing overhead
> will be minimized.

Petr is right, the zero parameter tick() is sort of active polling which may
be a performance killer, you either should go for the two parameters tick
in order to limit the "ticking rate" or use the CERTI specific tick2() function.
tick2() is equivalent to tick(INF,INF)

As shown ìn your source code you seems to have tried the two options
could you tell us if using the other tick variant exhibits different
performance?

>       while( fedamb->isAdvancing )
>       {
>               rtiamb->tick(); //rtiamb->tick(0.001,0.02);
>       }

By the way I do have another question,  are you comparing CERTI to other RTI?
If it is the case I would be interested in knowing some figures.
We do not compete with commercial RTI but knowing some user's experience
would be interested for us.

-- 
Erk