[kepler-dev] Re: orbstat in java (was Re: Roadnet Kepler demo)
tobin at splorg.org
Wed Dec 8 21:10:16 PST 2004
On Wed, 8 Dec 2004, Bertram Ludaescher wrote:
> >>>>> "TF" == Tobin Fricke <tobin at splorg.org> writes:
> TF> Another matter that we should look into is the responsiveness of these
> TF> actors. They tend to block while waiting for data to come in from the orb
> TF> (or something), making the Kepler UI extremely nonresponsive while the
> TF> workflows are executing. Maybe the Orb*Source components could do their
> TF> orb.get() call in a separate thread, or something.
> The reason for the non-responsiveness could very well be the "wrong"
> choice of the Ptolemy director. For example, recall that SDF does a
> single-threaded execution, serializing all fire operations.
This is almost certainly the case.
Right now, the OrbWaveformSource actor, on each firing, gets a packet from
the Orb, and disassembles this packet into samples, and then sends each of
these samples, individually, to its output port.
I propose to change it so that the OrbWaveformSource actor, on its first
firing, gets a packet from the Orb and outputs only the first sample from
the packet. On subsequent firings the actor will output subsequent
samples, until it's exhausted the samples present in the retrieved packet
and it needs to get another packet from the Orb. This would make
Another possibility would be to have OrbWaveformSource output an ARRAY of
samples, corresponding to the samples present in a single packet, on each
firing. I suspect this would lead to vastly more efficient processing,
although all downstream actors would have to act on arrays.
Orb packets, in general, contain a variable number of samples, which makes
static scheduling difficult.
More information about the Kepler-dev