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).
> 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....
simLogs.xlsx