From dbc5dd6a30b170324daaf54110e4a38c44aedd1b Mon Sep 17 00:00:00 2001 From: Byeonggil Jun Date: Tue, 14 Jan 2025 16:17:13 -0700 Subject: [PATCH 1/2] Add a draft explanation of DNET --- .../writing-reactors/distributed-execution.mdx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx b/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx index 0c8acb99d..626e252be 100644 --- a/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx +++ b/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx @@ -223,6 +223,20 @@ If, in addition, the physical clocks on the hosts are allowed to drift with resp With centralized coordination, all messages (except those on [physical connections](#physical-connections)) go through the RTI. This can create a bottleneck and a single point of failure. To avoid this bottleneck, you can use decentralized coordination. +### Optimization of Communication Overhead + +To reduce the communication of centralized coordination overhead caused by signals for coordinating federates, a signal named **Downstream Next Event Tag** (**DNET**) is introduced. This signal is beneficial if federates send the actual output (tagged message) sparsely, which is a frequent pattern in Cyber-Physical Systems, e.g., systems sensing the environment frequent but the actual event happens rarely. + +Although the effectiveness of this signal depends on the characteristic (how sparsely federates produce messages) and the structure (how federates are connected) of the program, the signal **DNET** is enabled by default because the benefit is crucially high in the best case scenarios and the drawback is limited even in the worst case scenarios. Users can simply disable this feature by specifying the target property: +``` +DNET: false +``` +Here are some giudelines to help determine whether to use this optimization techinque or not. +- When federates send tagged messages every time, the **DNET** signal cannot give any benefits. +- When a federate has a physical action and the federate may receive a tagged message from another federate, the **DNET** signal may increase the response time of the physical action by up to 2 times and uses may consider disabling it. + +Ongoing researches will formulate the method to automatically decide the benefit of the **DNET** signal or turn on and off this feature dynamically in the runtime. + ## Decentralized Coordination The default coordination between mechanisms is **centralized**, equivalent to specifying the target property: From c2f8701478edeb082511aa4e8f68c8af1be8bd48 Mon Sep 17 00:00:00 2001 From: Byeonggil Jun Date: Thu, 16 Jan 2025 17:28:32 -0700 Subject: [PATCH 2/2] Add reference link to the paper explaining the DNET signal --- .../version-0.9.0/writing-reactors/distributed-execution.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx b/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx index 626e252be..80ba824dc 100644 --- a/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx +++ b/versioned_docs/version-0.9.0/writing-reactors/distributed-execution.mdx @@ -225,7 +225,7 @@ With centralized coordination, all messages (except those on [physical connectio ### Optimization of Communication Overhead -To reduce the communication of centralized coordination overhead caused by signals for coordinating federates, a signal named **Downstream Next Event Tag** (**DNET**) is introduced. This signal is beneficial if federates send the actual output (tagged message) sparsely, which is a frequent pattern in Cyber-Physical Systems, e.g., systems sensing the environment frequent but the actual event happens rarely. +To reduce the communication of centralized coordination overhead caused by signals for coordinating federates, a signal named **Downstream Next Event Tag** (**DNET**) is introduced. This signal is beneficial if federates send the actual output (tagged message) sparsely, which is a frequent pattern in Cyber-Physical Systems, e.g., systems sensing the environment frequent but the actual event happens rarely. For more information, please refer to [this paper](https://ieeexplore.ieee.org/document/10740771). Although the effectiveness of this signal depends on the characteristic (how sparsely federates produce messages) and the structure (how federates are connected) of the program, the signal **DNET** is enabled by default because the benefit is crucially high in the best case scenarios and the drawback is limited even in the worst case scenarios. Users can simply disable this feature by specifying the target property: ```