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

[Gotthard, Petr]

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

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Vaibhav Bansal
Sent: Friday, August 28, 2009 10:32 AM
To: 'CERTI development discussions'
Subject: RE: [certi-dev] certi with HLA_USES_UDP

Thanks again for the quick reply.

1. If HLA_USE_UDP was not set, in my case, The rtig log did not show any
send/receive on UDP.
2. Time coordination was not enabled, most of the attributes were using
best_effort.
3. Parameter less tick() was being used.
4. 4 objects @ around 100Hz were being used for testing, later we will
require more objects though.
5. In our app loop, we call updateAttributeValues on RTIambassador, and then
call tick(), per frame.
6. Yes rtig, and 1 federate were running on same host. I used windows, the
federation was homogeneous.
7. Yes, that might be the case. I am new to this whole HLA stuff, so might
be doing something terribly wrong.

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

Best Regards,
Vaibhav Bansal

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

2009/8/27 Vaibhav Bansal <address@hidden>:
> Thanks for the quick reply.
>
> 1. Yes I did recompile after the changes.

OK.

> 2. I had transport of both types, reliable as well as besteffort in my
FOM,
>        Does enabling the flag, disable reliable transport?

I'm afraid so.
I'll dig up in CERTI history in order to check why we did that in past,
unfortunately I wasn't working on CERTI back then.

The baseline, i.e. if HLA_USES_UDP is not set, then object class attributes
or interaction flagged with BestEffort uses UDP link where Reliable use TCP.

> 3. Regarding subscribing to the mailing list, I think I might have set a
> different default sending ID.

Should be the case. If it bother you I may add alternate ID in the mailing
list whitelist. If you want that send me a private e-mail with
   - your subscription address
   - the other ID you may want to use

>        I am already subscribed to the list, and I received the message.
> Thanks for replying to the last mail.

> 4. Regarding using UDP, I felt that there was quite a bit of lag when only
a
> few objects were present in my Federates.

Are your federate using time coordination (and thus timestamp version of
UAV) ?

Do the attribute use Reliable or BestEffort?

Which version of the tick function are you using:
RTI::RTIambassador::tick(TickTime minimum, TickTime maximum)
or
RTI::RTIambassador::tick() ?

How much is few objects ?
May be you can tell us what of performance you expect?
A 100Hz loop sending 10 objects? A 250Hz sending 100 objects?

Do you expect kind of "synchronous" send/receive of object in a graphic loop
displaying the objects or does the HLA exchange asynchroneoulsy feeds
the display loop?

May be you can tell us your running configuration too,
how many Federate, do the RTIG and federate run on the same host,
what kind of host (Windows, Linux, ...), is the federation homogeneous
of heterogeneous (endianity mix, 32/64 bits mix etc...)

CERTI performance problems did not usually come from TCP vs UDP choice
so I would not look into that **in the first place** but examine other
"usual" perf. killer and go back to TCP vs UDP afterwards.

> 5. I will try to browse through the code of certi a bit, and will file the
bug.

Go ahead bugs report are welcome, even if I feel that for
that one I would have to know WHY we did this in the first place.

The "pure performance" reason does not seem a good reason for me
because for "small" amount of objects TCP may not be the culprit.

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





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