The discrete event (DE) domain in MLDesigner provides a general environment for time-oriented simulations of systems such as queuing networks, communication networks, and high-level models of computer architectures.
In this domain, each Particle represents an event that corresponds to a change of the system state. The DE schedulers process events in chronological order. Since the time interval between events is generally not fixed, each particle has an associated timestamp. Timestamps are generated by the block producing the particle based on the timestamps of the input particles and the latency of the block.
The DE target and its schedulers
The DE domain, at this time, has only one target. This target has two parameters:
||(float) Default = 1.0
||A scaling factor relating local simulated time to the time of other domains that might be communicating with DE.
||(enum) Default = Priority Free Scheduler
||Indicates which scheduler to use to simulate the model:
- Calendar Queue Scheduler
- Mutable Calendar Queue Scheduler
- Priority Free Scheduler
- Priority Scheduler
- Resource Contention Scheduler
- Simple DE Scheduler
The DE schedulers in MLDesigner determine the order of execution of the blocks. There are six schedulers that have been implemented which are distributed with the domain. They expect particular behavior (operational semantics) on the part of the primitives. In this section, we describe the semantics.
Events and chronology
A DE primitive models part of a system response to a change in the system state. The change of state, which is called an event, is signaled by a particle in the DE domain.
"Time" in the DE domain means simulated time. The DE domain may be used in combination with other domains in MLDesigner, even if the other domains do not have a notion of simulated time.
DE Performance Issues
DE Performance can be an issue with large, long-running systems. Below we discuss a few potential solutions. The calendar queue scheduler is not always the one to use. It works well as long as the ”density” of events in simulated time is fairly uniform. But if events are very irregularly spaced, you may get better performance with the simpler scheduler, because it makes no assumptions about timestamp values. For example, it has been reported that the CQ scheduler did not behave well in a simulation that had a few events at time zero and then the bulk of the events between times 800000000 and 810000000 – most of the events ended up in a single CQ ”bucket”, so that performance was worse than the simple scheduler. It also has been pointed out that both the CQ and simple schedulers ultimately depend on simple linear lists of events. If your application usually has large numbers of events pending, it might be worth trying to replace these lists with genuine priority queues (i.e., heaps, with \fs1 O(log N) rather than \fs1 O(N) performance). But you ought to profile first to see if that’s really a time sink. Another thing to keep in mind, the overhead for selecting a next event and firing a primitive is fairly large compared to other domains such as SDF. It helps if your primitives do a reasonable amount of useful work per firing; that is, DE encourages ”heavyweight” primitives. One way to get around this is to put purely computational subsystems inside SDF wormholes. As discussed previously, an SDF-in-DE wormhole acts as a zero-delay primitive. One way to gain a slight amount of speed is to avoid the GUI interface entirely by using PTcl, which does not have Tk primitives.
The model of computation in the DE domain makes it amenable to high-level system modeling. For this reason, primitives in the DE domain are often more complicated, and more specialized than those in the SDF domain.