You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow users to specify the expected computational delay of a node callback
Allow delay variation (both computation and input delays).
Relay effective output delay by appending it to output messages
Infer effective callback output delay from computational delay, blocking characteristic of all input channels and their delays.
Motivation
The inter-node communication delays within a graph can be modeled as a combination of computational and communication delays. The delay of upstream nodes affect the effective delay of downstream nodes when intermediate connections are blocking. For realistic delay simulation in mixed graphs (graphs with both blocking and non-blocking connections), this should be modeled appropriately.
Moreover, delays are often not fixed but stochastic. Users should be allowed to vary (communication, computation) delays during an episodes. Allow delays to vary may lead to unintended behavior such as message reordering when a message is delayed by so much that it is "overtaken" by the following message. Should reordering be optional, or should we block it all together?
Checklist
I have checked that there is no similar issue in the repo (required)
The text was updated successfully, but these errors were encountered:
🚀 Feature
Motivation
The inter-node communication delays within a graph can be modeled as a combination of computational and communication delays. The delay of upstream nodes affect the effective delay of downstream nodes when intermediate connections are blocking. For realistic delay simulation in mixed graphs (graphs with both blocking and non-blocking connections), this should be modeled appropriately.
Moreover, delays are often not fixed but stochastic. Users should be allowed to vary (communication, computation) delays during an episodes. Allow delays to vary may lead to unintended behavior such as message reordering when a message is delayed by so much that it is "overtaken" by the following message. Should reordering be optional, or should we block it all together?
Checklist
The text was updated successfully, but these errors were encountered: