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

[Vaibhav Bansal]

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.

Also federate does not include any
RTI::RTIambassador::enableTimeRegulation
nor
RTI::RTIambassador::enableTimeConstrained


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)
.........................................................................

Thanks and Regards
Vaibhav Bansal

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

2009/8/28 Gotthard, Petr <address@hidden>:
> Vaibhav,
> When saying you call the parameter less tick() "per frame", what is the
"fps" rate? Is the lag increasing?
>
> The parameter less tick() does process only 1 callback, so if you include
tick() directly in the visualization loop with e.g. 10fps, you can process
only 1 object @ 10Hz without a lag. If you have more objects and/or higher
frequency, the updates are being queued and processed at 10Hz. (The queue
and the lag are increasing.)
>
> You may try using tick(0, 1). It will process all available updates in
each frame.

Petr is right (as usual :-), one more thing you can do when you are
re-trying with appropriate
tick call is to give us the RTIA statistics you get when your
federates terminates.
Statistics looks like:
RTIA: Statistics (processed messages)
List of federate initiated services
--------------------------------------------------
       1 Message::CREATE_FEDERATION_EXECUTION (MSG#2)
       2 Message::DESTROY_FEDERATION_EXECUTION (MSG#3)
       1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
 ....
List of RTI initiated services
--------------------------------------------------
    6542 NetworkMessage::MESSAGE_NULL (MSG#2)
       4 NetworkMessage::SET_TIME_REGULATING (MSG#7)
       1 NetworkMessage::TIME_REGULATION_ENABLED (MSG#9)
       1 NetworkMessage::TIME_CONSTRAINED_ENABLED (MSG#10)
 Number of Federate messages : 29606
 Number of RTIG messages : 13188

This we (and you) will see which kind of message your federate is using for
sure
and  the amount of message sent.

I'd like to add that in tick(0,1),
0 means that tick will return immediatly if there is no callback pending and
1 that it will continue to process callbacks either until all callbacks
are done or 1 second duration is reach.

Since you have a 100Hz loop, it should theoretically
be tick(0,0.01) or even less tick(0,0.01-otherActivityExpectedDuration) but
I don't whether if the  clock resolution would be sufficient to support such
value (0.01).

Moreover you said:
> > 2. Time coordination was not enabled, most of the attributes were using
best_effort.

So would you confirm you federate does not include any
RTI::RTIambassador::enableTimeRegulation
nor
RTI::RTIambassador::enableTimeConstrained

calls?

>  On a side note, I tried with portico, and free version of MAK RTI and
they were not showing any lag.

Good to know, CERTI should be able to give you as good result as
Portico and MAK,
may be those RTI have a different default behavior regardind the
tick() parameter-less function.

Current Portico-1.0 API doc seems to confirms that fact:
http://portico.sourceforge.net/javadoc/portico-1.0/org/portico/impl/hla13/Rt
i13Ambassador.html#tick%28%29
says "Keeps processing the callback queue until it is empty
(regardless of how long that takes) "

Concerning MAK I don't know.

I did check the last RTIG-NG doc I had and I found that
"The zero-argument variant of tick reads all available network
 traffic, then does as much processing as possible without blocking
 for additional network communications. This may result in many
 federate-ambassador notifications being delivered to the federate.
 The federate should not rely on the zero-argument variant of
 tick() completing execution in any particular interval of time."

thus CERTI may  not be RTI-NG compatible on this.
Pierre, Petr,
Can you confirm?
Do you think it deserve a bug report (and a patch)?

May be we can add a tick_ng() which is RTI-NG compatible
or rename tick() to tick_once() or tick_certi()
and then create tick() to be RTI-NG compatible....

More discussion on this on the tracker if you find it useful.

-- 
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