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

[Eric Noulard]

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/Rti13Ambassador.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