FLOAT) Default = 1.0
A scaling factor relating local simulated time to the time of other domains that might be communicating with DE.
INT) Default = YES
An experimental optimization explained below, again aimed at mixed-domain systems.
INT) Default = YES
A Boolean indicating whether or not to use the faster "calendar queue" scheduler, explained below.
Each scheduler maintains a global event queue where particles currently in the system are sorted in accordance with their time stamps; the earliest event in simulated time being at the head of the queue. The difference between the two schedulers is primarily in the management of this event queue. Anindo Banerjea and Ed Knightly wrote the default DE Scheduler, which is based on the "calendar queue" mechanism developed by Randy Brown [Bro88]. (This was based on code written by Hui Zhang.) This mechanism handles large event queues much more efficiently than the alternative, a more direct DE scheduler, which uses a single sorted list with linear searching. The alternative scheduler can be selected by changing a parameter in the default DE target.
Each scheduler fetches the event at the head of the event queue and sends it to the input ports of its destination block. A DE star is executed (fired) whenever there is a new event on any of its input portholes. Before executing the star, the scheduler searches the event queue to find out whether there are any simultaneous events at the other input portholes of the same star, and fetches those events. Thus, for each firing, a star can consume all simultaneous events for its input portholes. After a block is executed it may generate some output events on its output ports. These events are put into the global event queue. Then the scheduler fetches another event and repeats its action until the given stopping condition is met.
It is worth noting that the particle movement is not through Geodesics, as in most other domains, but through the global queue in the DE domain. Since the geodesic is a FIFO queue, we cannot implement the incoming events which do not arrive in chronological order if we put the particles into geodesics. Instead, the particles are managed globally in the event queue.
RepeatStar.
RepeatStar is also used by stars that do have input portholes, but also need to schedule themselves to execute at particular future times whether or not any outside event will arrive then. An example is PSServer.
In a RepeatStar, a special hidden pair of input and output ports is created and connected together. This allows the star to schedule itself to execute at any desired future time(s), by emitting events with appropriate time stamps on the feedback loop port. The hidden ports are in every way identical to normal ports, except that they are not visible in the graphical user interface. The programmer of a derived star sometimes needs to be aware that these ports are present. For example, the star must not be declared to be a delay star (meaning that no input port can trigger a zero-delay output event) unless the condition also holds for the feedback port (meaning that refire events don't trigger immediate outputs either). See the Programmer's Manual for more information on using RepeatStar.
The choice of which to fire is made in Ptolemy by statically assigning priorities to the stars according to a topological sort. Thus, if one of two enabled stars could produce events with zero delay that would affect the other, as shown in figure
Detecting delay-free loops reliably is difficult. Some stars, such as Server and Delay, take a parameter that specifies the amount of delay. If this is set to zero, it will fool the scheduler. It is the user's responsibility to avoid this pathological case. This is a special case of a more general problem, in which stars conditionally produce zero-delay events. Without requiring the scheduler to know a great deal about such stars, we cannot reliably detect zero-delay loops. What appears to be a delay-free path can be safe under conditions understood by the programmer. In such situations, the programmer can avoid the error message placing a delay element on some arc of the loop. The delay element is the small green diamond found at the top of every star palette in Pigi. It does not actually produce any time delay in simulated time. Instead, it declares to the scheduler that the arc with the delay element should be treated as if it had a delay, even though it does not. A delay element on a directed loop thus suppresses the detection of a delay-free loop.
Another way to think about a delay marker in the DE domain is that it tells the scheduler that it's OK for a particle crossing that arc to be processed in the "next" simulated instant, even if the particle is emitted with timestamp equal to current time. Particles with identical timestamps are normally processed in an order that gives dataflow-like behavior within a simulated instant. This is ensured by assigning suitable firing priorities to the stars. A delay marker causes its arc to be ignored while determining the dataflow-based priority of star firing; so a particle crossing that arc triggers a new round of dataflow-like evaluation.
If the SDF subsystem in figure 12-2 is a multirate system, the effects are somewhat more subtle. First, a single event at the input may not be sufficient to cycle through one iteration of the SDF schedule. In this case, the SDF subsystem will simply return, having produced no output events. Only when enough input events have accumulated at the input will any output events be produced. Second, when output events are produced, more than one event may be produced. In the current implementation, all of the output events that are produced have the same time stamp. This may change in future implementations.
Sampler star, therefore, is introduced to produce an output event at the current simulation time. This output event, therefore, is produced before the DE scheduler returns control to the output SDF scheduler.
The behavior shown in figure
12-3 may not be the desired behavior. The Sampler star, given an event on its control input (the bottom input), copies the most recent event from its data input (the left input) to the output. If there has been no input data event, then a zero-valued event is produced. There are many alternative ways to ensure that an output event is produced. For this reason, the mechanism for ensuring that this output event is produced is not built in. The user must understand the semantics of the interacting domains, and act accordingly.
The mechanism for handling this situation is simple. When the internal domain is initialized or fired, it can, before returning, place itself on the event queue of the outer domain, much the same way that an event generator star would. This ensures that the inner event will be processed at the appropriate time in the overall chronology. Thus, when a timed domain sits within a timed domain wormhole, before returning control to the scheduler of the outer domain, it requests rescheduling at the time corresponding to the oldest time stamp on its event queue, if there is such an event.
When an internal timed domain is invoked by another time domain, it is told to run until a given "stop time," usually the time of the events at the inputs to the internal domain that triggered the invocation. This "stop time" is the current time of the outer scheduler. Since the inner scheduler is requested to not exceed that time, it can only produce events with time stamp equal to that time. Thus, a timed domain wormhole, when fired, will always either produce no output events, or produce output events with time stamp equal to the simulated time at which it was fired.
To get a time delay through such a wormhole, two firings are required. Suppose the first firing is triggered by an input event at time
With this conservative style of timed interaction, we say that the DE domain operates in the synchronized mode. Synchronized mode operation suffers significant overhead at run time, since the wormhole is called at every time increment in the inner timed domain. Sometimes, however, this approach is too conservative.
In some applications, when an input event arrives, we can safely execute the wormhole into the future until either (a) we reach the time of the next event on the event queue of the outer domain, or (b) there are no more events to process in the inner domain. In other words, in certain situations, we can safely ignore the request from the output domain that we execute only up until the time of the input event. As an experimental facility to improve run-time efficiency, an option avoids synchronized operation. Then, we say that the DE domain operates in the optimized mode. We specify this mode by setting the target parameter syncMode to FALSE (zero). This should only be done by knowledgeable users who understand the DE model of computation very well. The default value of the syncMode parameter is TRUE (one), which means synchronized operation.
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, Tom Lane 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.
Tom Lane also 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 O(log N) rather than O(N) performance). But you ought to profile first to see if that's really a time sink.
Another thing to keep in mind that the overhead for selecting a next event and firing a star is fairly large compared to other domains such as SDF. It helps if your stars do a reasonable amount of useful work per firing; that is, DE encourages "heavyweight" stars. One way to get around this is to put purely computational subsystems inside SDF wormholes. As discussedpreviously, an SDF-in-DE wormhole acts as a zero-delay star.
If you are running a long simulation, you should be sure that your machine is not paging or worse yet swapping; you should have plenty of memory. Usually 64Mb is enough, though 128Mb can help (gdb takes up a great deal of memory when you use it, too.). Depending on what platform you are on, you may be able to use the program top (ftp://eecs.nwu.edu/pub/top). You might also find it useful to use iostat to see if you are paging or swapping.
One way to gain a slight amount of speed is to avoid the GUI interface entirely by using ptcl, which does not have Tk stars. See
"Some hints on advanced uses of ptcl with pigi" on page 3-19 for details.