-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Downstream next event tag (DNET), a new signal for more efficient centralized federated execution #349
base: main
Are you sure you want to change the base?
Conversation
…ery possible connection This is a preparation step for the DNET message calculation. This matrix enables each federate to search min_delays from upstreams as well as to downstreams. Use a matrix instead of multiple arrays to store minimum delays of every possible connection This is a preparation step for the DNET message calculation. This matrix enables each federate to search min_delays from upstreams as well as to downstreams.
121e21f
to
79e2fdb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need more time to review this, but here is a starting point. This is looking very good so far. I have a few suggestions, some of which are just nits and you should feel free to ignore them. I will follow up with a more complete review as soon as I can.
Co-authored-by: Edward A. Lee <eal@eecs.berkeley.edu>
The example given in the PR comment is confusing. It says: For example, if the delay from What does it mean " The rest of the example is irrelevant to this PR. The statement it makes is true without this PR and has always been true. Can you instead give an example that actually uses this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried about the n^2 complexity and memory cost. I've added some suggestions, but I think the all_upstream
, all_downstream
, and min_delay
arrays all have n^2 complexity in the worst case and they seem redundant. I'm suggesting consolidating to just use the min_delay
array for all these purposes.
Hello, @edwardalee.
What I meant was "the minimum tag of the most recent NET_B and the head of the in-transit message queue of
I don't get what transitive NET is. Could you please elaborate on it?
I tried to explain how a DNET signal is used in the example. Could you read it and share your thoughts? |
OK, the description is much better now. I would suggest a slight enhancement. Instead of: "Based on the DNET signal, A does not send any NET signals with tags earlier than or equal to (100 ms, 0) (NET with 10 ms, 20 ms, ..., 100 ms)" you could say: "Based on the DNET signal, if A is not producing outputs, A does not need to send any NET signals with tags earlier than or equal to (100 ms, 0) (NET with 10 ms, 20 ms, ..., 100 ms)" |
This PR replaces #176 and #337.
Relevant discussion and issue: lf-lang/lingua-franca#1626, #264
A companion PR in lingua-franca: lf-lang/lingua-franca#2400
A companion PR in reactor-ts: lf-lang/reactor-ts#296
In this PR, the new message type, downstream next event tag (DNET), is introduced to reduce unnecessary NET signals. This signal is sent from the RTI to a federate to notify it that NET tags below some threshold are unnecessary, and not needed by its downstream federates.
Suppose the RTI is computing the DNET tag for a federate
A
whereA
has one downstream federateB
. The RTIuses the minimum delay between the federates and
B
's NET value to compute the DNET tag. For example, suppose the delay fromA
toB
isNEVER
andA
has an event every10 ms
(0
,10 ms
, ...). Also, assume B's next event is at(100 ms, 0)
. The RTI knows B's next earliest event tag by finding the minimum tag of the most recent NET_B and the head of the in-transit message queue ofB
is(100 ms, 0)
.In this case, the RTI can send
DNET (100 ms, 0)
toA
. Based on the DNET signal, if A is not producing outputs, A does not need to send any NET signals with tags earlier than or equal to (100 ms, 0) (NET with 10 ms, 20 ms, ..., 100 ms) because the RTI cannot sendTAG (100 ms, 0)
using those NET signals. The RTI can grantTAG (100 ms, 0)
toB
after receivingNET (110 ms, 0)
fromA
.Additionally, in this PR, the RTI computes the tag of the signal tag advance grant (TAG) with the earliest incoming message tag (EIMT) to prevent blocking a federate that is eligible to advance its tag. Currently, if a federate has its next event scheduled at
(100 ms, 0)
and its EIMT is(200 ms, 1)
, the RTI sendsTAG (100 ms, 0)
. However, this incurs unnecessary NET signals if the federate has an event at the tag (200 ms, 0). So in this PR, the RTI sendsTAG (200 ms, 0)
(the latest earliest tag of EIMT) so that the federate can execute any potential events with tags earlier than(200 ms, 1)
as well as the event at(100 ms, 0)
.This PR also contains some refactoring for the data structure used by the RTI to store delays between federates. A two-dimensional matrix stores the delays now.