certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] late arriving federate


From: address@hidden
Subject: Re: [certi-dev] late arriving federate
Date: Sat, 3 Oct 2009 16:59:53 +0200

Mathias,

I think you are right. We will discuss this issue with Eric
tomorrow.

Martin

---------- Initial Header -----------

From      :
address@hidden
To          : CERTI development discussions
<address@hidden>
Cc          : 
Date      : Sat, 3 Oct 2009 16:24:55 +0200
Subject : Re: [certi-dev] late arriving federate

2009/9/27 Mathias Fröhlich <address@hidden>:
> Hi,
>
> I try to get up two federates both time constrained and
time regulating.
> One starts up immediately enables time constrained gets 0
as federate time in
> the timeConstrainedEnabled callback, past that it calls
> enableTimeRegulation(0, 0.1) gets back a federate time of
0.1 in the
> timeRegulationEnabled callback. Then classes are
subscribed and objects
> registered and the regular timeAdvanceRequest/update loop
is entered.
>
> At some later time, a second federate joins the federation
and executes the
> same code as above with a different federate name and so on.
> The second federate also gets 0 and 0.1 in the appropriate
callbacks.

This looks strange to me.

> But then the first federate stops getting timeAdvanceGrant
callbacks until the
> second federate's federation time has reached the same
numeric value than the
> federation time of the first federate. Then the time
advances again in both
> federates.

However, considering the first weird behavior, this behavior
looks good.

> I would expect that from within the timeRegulationEnabled
call I get the
> actual minimum logical time I need to become time
regulating instead of
> stopping the other federates until the new one catches up.

You are pretty right.

> Portico behaves like expected.
> Well in contrast to portico certi behaves very different
wrt the federate time
> and lbts and the time values returned in the
timeConstraintEnabled and
> timeRegulationEnabled.
> Since I do not have any standard document for HLA/ieee1516
available I am not
> sure how this is supposed to work, but at least I would
think that certi's
> behavior is wrong and to me, porticos behavior looks much
more plausible.

I'll check the standard regarding this, but intuitively I
think your are right.
Pierre, Petr, Martin [Adele],
may be some of you already have a clean answer for this.

> I have done a patch to rtig to return at least something
that is about at the
> current logical time of the federation in the
timeRegulationEnabled callback.
> But I believe that this change is still wrong since it
returns the lbts
> instead of the federate time if I understand right.
> Anyway, I do not really understand the current
implementation to its end, so I
> have just attached the change that appears to improve the
situation as a
> discussion base for a correct solution.

Whatever the solution, this issue needs to be bug-tracked
properly.
Would you be kind enough to open a bug in the tracker for this
https://savannah.nongnu.org/bugs/?group=certi

and attach your patch proposal to the bug.
(you may attach some files to a previously submitted bug
 see the "Attached Files" section of the bug)

> Knowledge, suggestions, hints?
> ... help?

Not much now, just coming back from one "no-network" week :-)
More information to come.

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



Martin Adelantado
-----------------------------------------------------------------------------
06 07 47 78 23                                             
                       
Web : http://www.cert.fr/anglais/deri/adele/adele_fr.html 
-----------------------------------------------------------------------------


---------------------- ALICE N°1 de la RELATION CLIENT 2008*--------------------
Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici 
http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES 
/ BEARING POINT. Secteur Fournisseur d.Accès Internet






reply via email to

[Prev in Thread] Current Thread [Next in Thread]