Re: [certi-dev] certi with HLA_USES_UDP / tick

[Eric Noulard]

2009/8/28 Vaibhav Bansal <address@hidden>:
> Hello
>
> Sorry for sending incomplete log.

No problem.

> I had two federates, first was used just to send objects.

OK.
The two federate and the RTIG are running on the same Windows host right?

> The other federate was used just to receive those objects, and did not send
> any attribute updates itself.
> This federate was having its reflect attribute called.

Is the receiving federate the one displaying something using Delta3D
running in a 100Hz loop?

Which federate seems to lag? Both ?
Only the receiving one?

> Here is the log for both the federates:

[...]

Those are more understandable.
Could you tell us the average number of CERTI message per second
those logs represents?

We have the number of message but not the elapse (wall-clock) time for those.

> 1. The sending federate:
> ........................................................................
> RTIA: Statistics (processed messages)
> List of federate initiated services
> --------------------------------------------------
[...]
>    4515 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
[...]
>     905 Message::TICK_REQUEST (MSG#141)

Since the sending federate is not expecting any callback
you'd better call tick() or tick(0,0.001) in order to stay as less
time as possible ticking.

> 2. The receiving federate:
> ........................................................................
> RTIA: Statistics (processed messages)
> List of federate initiated services
> --------------------------------------------------
[...]
>    4466 Message::TICK_REQUEST (MSG#141)
>    3704 Message::TICK_REQUEST_NEXT (MSG#142)
>
> List of RTI initiated services
> --------------------------------------------------
[...]
>    4515 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)
>     354 NetworkMessage::GET_FED_FILE (MSG#84)

You seem to be ticking to fast because as far as I understand you
should expect 1/5 ratio between
 TICK_REQUEST and REFLECT_ATTRIBUTE_VALUES.

since you seem to send something like 5 UPDATE_ATTRIBUTE_VALUES
per cycle in your sending federate.

> Adding RTI::RTIambassador::enableAsynchronousDelivery() did not help either.

That's normal behavior I was seeking for bug.
You should remove the call since it is not necessary.


Would you be able to run your test on a Linux box?
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org