Re: [certi-dev] NextEventRequestAvailable and LBTS - Possible deadlock?

[Eric Noulard]

2010/7/6 Ijperen, Jeroen van <address@hidden>:
> Hello,
>
> Currently I am having some difficulties getting my time constrained federates 
> to work with Certi. Each federate uses "NextEventRequestAvailable" to advance 
> their time, but none receive a TimeAdvanceGrant...

Hi Jeroën,

I did work on TimeManagement improvement with Pierre.
There were some bugs and we propose some enhancement too.

bugs:

   - NERA wasn't granted if LTBS was equal to LBTS which was wrong
     because NERA (and TARA) should bring you up to LBTS, LBTS included
     whereas TAR and NER should not. See §8.1 from HLA document (both
1.3 and 1516)

 -  The Zero lookahead handling was buggy in the NER case, a stupid typo
     for which "==" (test) was there instead "=" (assignment) would
prevent zero-lookahead
     federate to progress using NER.

enhancement:

  - In order to improve the time progression of federate progressing
with NER/NERA we
     implemented the proposition from Pierre. This may be called NULL
PRIME message protocol.
     This feature can be optionnally set to ON (default is OFF) at
compile time using the
     CMake option CERTI_USE_NULL_PRIME_MESSAGE_PROTOCOL.
     I'll try to start another discussion concerning this feature but
be aware this is
     to be considered "experimental" until we go through a thorough
validation of the new protocol.


> My federation starts as follows:
> 1. Federate A starts, joins and becomes time constrained and time regulating
> 2. Federate A does a NERA (NextEventRequestAvailable) for time 1.0
> 3. Federate A received a TAG (TimeAdvanceGrant) callback for time 1.0
> 4. Federate B starts, joins and becomes time constrained
> 5. Federate B does a NERA for time 1.0
> 6. Federate B received a TAG callback for time 1.0
> 7. Federate A does a NERA for time 2.0 and waits for a TAG...
> 8. Federate B does a NERA for time 2.0 and waits for a TAG...
>
> Internally I see that at point 7 Federate A compares its requested time (2.0) 
> to the LBTS, which is 1.0 (the time Federate B was granted at 6). Since its 
> request is higher than the LBTS it keeps waiting. At point 8 Federate B 
> compares its requested time (also 2.0) to the LBTS, which is 1.0 (the time 
> Federate A was granted at 3).
>
> At this point in time both Federates are deadlocked as far as NERA is 
> concerned.
>
> Can you reproduce this sequence of events, and how can we fix this?

I think you testcase should now be OK with the bug fixes in CVS now.
If you have time you can try the experimental "NULL PRIME MESSAGE" protocol
which should make you federation even more efficient wrt time advance.

> From what I understood from the standard, is that a NERA can get a TAG 
> response with a lower time than requested, at the moment it receives TSO 
> messages for that lower time. I do not see this behavior in CERTI... I think 
> it is required, so that the LBTS can be updated with the requested times, as 
> long as no TSO messages need to be delivered for earlier times.

I think you are right.
I'm not sure this currently works (receiving a TAG lower than expected
time)  however
I don't  think this is the issue you have now.


Jeroen would you be able to give us an update on your status regarding
this issue
(and confirm you use Zero Lookahead federate) ?

I'd like to make a CERTI 3.4.0 release not too far from now and I
think it would be great
if it could suits your needs too.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org