certi-devel
[Top][All Lists]
Advanced

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

Re: [certi-dev] NextEventRequestAvailable and LBTS


From: Massimiliano D'Angelo
Subject: Re: [certi-dev] NextEventRequestAvailable and LBTS
Date: Wed, 8 Aug 2012 16:20:59 +0200

Please find attached a log of the simulation which refers to the described scenario (I amn not sure that the attached file will be received by the mailing list members).
I am available to provide more information on the scenario in case the log is not clear enough.

Thanks,
Massimiliano

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. 
Is this a bug in the protocol implementation or have I misunderstood the protocol behaviour?
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. 
FYI, I am using the NULL PRIME MESSAGE PROTOCOL (the simulation freezes using the default protocol).

WDYT? 

Thanks,
Massimiliano

Attachment: simLogs.xlsx
Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet


reply via email to

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