Hi,
when a federate call the nextEventRequestAvailable(t1) a nullPrimeMessage with t1 is sent to the RTIG.
Lets suppose now that the RTIA does not give the grant and that a new TSO at t1 is passed to the federate.
The new message notify some events at t1 into the federate, that may call the nextEventRequestAvailable(t2) with t2<t1.
In this case the RTIS wont send the null prime message and the RTIG thinks that the federate is still ready to jump to t1 even if it is not anymore.
The part of the code that is responsible for it is in TimeManagment.cc line 135
[if ((logicalTime > lastNullMessageDate) || (logicalTime > lastNullPrimeMessageDate))]
i changed this in
[if ((logicalTime >= _heure_courante))
and things get abit better, but now it is necessary to adapt the RTIG code to correctly handle the nullprimeMessages that receives as it may receive NullPrimeMessages with timestamp lower than the one already received.
Alessandro
Da: certi-devel-bounces+address@hidden [certi-devel-bounces+address@hidden per conto di Massimiliano D'Angelo
address@hidden
Inviato: lunedì 27 agosto 2012 11.29
A: CERTI development discussions
Oggetto: Re: [certi-dev] NextEventRequestAvailable and LBTS
FYI, I have created a bug ticket.
https://savannah.nongnu.org/bugs/index.php?37204
2012/8/20 Massimiliano D'Angelo
<address@hidden>
Hi Eric,
thank you for your reply. Answers to your questions are in the text. I have also attached a log generated by the simulation that shows the issue that I have described. I hope it might be useful to understand where the issue is...
2012/8/16 Eric Noulard
<address@hidden>
2012/8/8 Massimiliano D'Angelo <address@hidden>:
> Hi guys,
> I am using CERTI and I have noticed an issue.
> I have two federates, say A and B, which are both regulating and
> constrained, with zero lookahead. I am using the NextEventRequestAvailable
> service.
> Let's suppose both federates are at time n and LBTS=n. Here is what happens:
> 1) Federate A performs a NextEventRequestAvailable(n+1)
> 2) Federate A receives a TSO at time n, and consequently the
> TimeAdvanceGrant to time n.
> 3) Federate B performs a NextEventRequestAvailable(n+1)
> 4) Federate B receives the TimeAdvanceGrant to time n+1. [IS THIS STRANGE?]
> 5) Federate A sends a TSO at time n
> 6) Federate B receives a TSO at time n, which is in the past with respect to
> its local time!!!
> I would have expected at point 4 to have B blocked up to the point in which
> the grant can actually be given (Federate A requests again to advance its
> time to n+1) or a TSO arrives.
Yes may be, but this is strange before that point
The TSO received by A on 2) is coming from B right?
Right.
Will do.
> Putting some printf in the RTIg, I noticed that once Federate A requires to
> advance to n+1 (step 1), the RTIg stores n+1 as clock value of federate A,
> and uses this value to calculate the LBTS. At point 3, when the RTIG
> receives the request of federate B, the RTIg calculates the LBTS assuming
> that both federates are at n+1. So, it seems it does not properly take into
> account that the request to move to time n+1 by federate A has not been
> granted.
The RTIG tries to maintain the LBTS by monitoring the NULL message
flow. The error is that when A) received address@hidden the RTIG shall have taken
the minimum between n and n+1 (computed from address@hidden+1).
> FYI, I am using the NULL PRIME MESSAGE PROTOCOL (the simulation freezes
> using the default protocol).
Standard protocol cannot handle NER with Zero-LK, it should work with TAR
and Zero-LK though.
Zero-LK handling is tricky, are you sure you need that?
Unfortunately yes....