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

[Vaibhav Bansal]

Hello again,

1. Yes, both the federates are running on same windows host, 
        Though the behavior does not differ much if two machines are used.
2. Yes, the federates also display objects, and the objects are nothing but
simple spheres
3. Only the receiving federate lags. (why would the sending federate lag?)
4. About 300 messages per second, (60Hz, 5 attributes updates per frame)
5. Yes, the ratio between TICK_REQUEST and REFLECT_ATTRIBUTE_VALUES should
be about 1:5, 
        I think that only one callback for reflectAttributes is being
processed, even after using tick(0,1).
6. Sorry, but it would not be possible to run my case on linux box.
        (btw does CERTI for windows differs too much from linux version?)

Thanks and Regards
-vaibhav

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

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


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