Re: [certi-dev] certi with HLA_USES_UDP

[Eric Noulard]

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