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

[Vaibhav Bansal]

Hello 

Sorry for sending incomplete log.

I had two federates, first was used just to send objects.
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.

Here is the log for both the federates:

1. The sending federate:
........................................................................
RTIA: Statistics (processed messages)
List of federate initiated services
--------------------------------------------------
       1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
       1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
       1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
       5 Message::REGISTER_OBJECT_INSTANCE (MSG#40)
    4515 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
       1 Message::ENABLE_ASYNCHRONOUS_DELIVERY (MSG#97)
       1 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
       2 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
     905 Message::TICK_REQUEST (MSG#141)

List of RTI initiated services
--------------------------------------------------
     354 NetworkMessage::GET_FED_FILE (MSG#84)

 Number of Federate messages : 5432
 Number of RTIG messages : 354
........................................................................

2. The receiving federate:
........................................................................
RTIA: Statistics (processed messages)
List of federate initiated services
--------------------------------------------------
       1 Message::CREATE_FEDERATION_EXECUTION (MSG#2)
       1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
       1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
       1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
       1 Message::ENABLE_ASYNCHRONOUS_DELIVERY (MSG#97)
       1 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
       5 Message::GET_OBJECT_CLASS_NAME (MSG#113)
       2 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
      10 Message::GET_ATTRIBUTE_NAME (MSG#115)
       5 Message::GET_OBJECT_CLASS (MSG#127)
    4466 Message::TICK_REQUEST (MSG#141)
    3704 Message::TICK_REQUEST_NEXT (MSG#142)

List of RTI initiated services
--------------------------------------------------
       5 NetworkMessage::DISCOVER_OBJECT (MSG#43)
    4515 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)
     354 NetworkMessage::GET_FED_FILE (MSG#84)
       1 NetworkMessage::START_REGISTRATION_FOR_OBJECT_CLASS (MSG#89)

 Number of Federate messages : 8198
 Number of RTIG messages : 4875
........................................................................


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

Thanks and Regards
Vaibhav Bansal



-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Eric Noulard
Sent: Friday, August 28, 2009 9:24 PM
To: CERTI development discussions
Subject: Re: [certi-dev] certi with HLA_USES_UDP / tick

2009/8/28 Vaibhav Bansal <address@hidden>:
> Hello again,
>
> I tried with tick(0, 1) as suggested, however the perceived lag did not
> disappear.
> This function still seems to process only 1 callback every tick.

That's not the expected behavior unless not all UAV have reached the RTIA
when the Federate is ticking.
but keep reading....

> Here is the Stat display:
> .....................................................................
> RTIA: Statistics (processed messages)
> List of federate initiated services
> --------------------------------------------------
>       1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
>       1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
>       1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
>       5 Message::REGISTER_OBJECT_INSTANCE (MSG#40)
>     475 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
>       1 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
>       2 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
>      96 Message::TICK_REQUEST (MSG#141)
>
> List of RTI initiated services
> --------------------------------------------------
>     354 NetworkMessage::GET_FED_FILE (MSG#84)
> .........................................................................

Those statistics are definitely weird.
As from the figures your federate did not received ANY callback at all!!!
(the call back should appear as "RTI initiated services")

Do you have more than 1 federate in the federation?
You should at least have 2 federates, unless I misunderstand
your HLA usage. If you only have 1 federate you usually do not expect
to receive the RAV
(Reflect Attribute Value)
corresponding to your own UAV
(Update Attribute Value).

The statistics of the current federate says that he did tick 96 times
and did 475 UAV for 5 registered objects.
Since 5*96 = 480, this seems OK.
(5 missing messages may be explained by an extra tick out of the
simulation loop).

Did your check if the overloaded
RTI::FederateAmbassador::reflectAttributeValues
in your Federate is called at least once ?

If not then it's logical that your federate is lagging because each
tick(0,1) will make it wait for 1 sec.

If you have more than 1 federate in your federation  could you

1) Send us the statistics for two federates who should exchange data
through UAV/RAV.

2) add a call to
RTI::RTIambassador::enableAsynchronousDelivery()
+
tick(0,1)
BEFORE entering your "simulation" loop
(and after joining the federation).

If you only have 1 federate in your testcase could you explain what you
expect him to do?


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


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