|
From: | Massimiliano D'Angelo |
Subject: | Re: [certi-dev] NextEventRequestAvailable and LBTS |
Date: | Mon, 27 Aug 2012 11:29:00 +0200 |
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,Yes may be, but this is strange before that point
> 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.
The TSO received by A on 2) is coming from B right?
Right.> Is this a bug in the protocol implementation or have I misunderstood theLooks like a bug, could you open a bug report
> protocol behaviour?
https://savannah.nongnu.org/bugs/?group=certi
and refer to this message on the ML:
http://lists.nongnu.org/archive/html/certi-devel/2012-08/msg00000.html
Will do.> Putting some printf in the RTIg, I noticed that once Federate A requires toThe RTIG tries to maintain the LBTS by monitoring the NULL message
> 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.
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).
Standard protocol cannot handle NER with Zero-LK, it should work with TAR
> FYI, I am using the NULL PRIME MESSAGE PROTOCOL (the simulation freezes
> using the default protocol).
and Zero-LK though.
Zero-LK handling is tricky, are you sure you need that?Unfortunately yes....--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
CERTI-Devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/certi-devel
[Prev in Thread] | Current Thread | [Next in Thread] |