On Sun, Aug 15, 2004 at 09:38:25AM -0700, David Beberman wrote:
I'm currently looking through the 2.1 version of GSR.
I want to confirm that I understand what I'm looking at.
There is only one execution thread for a flow from source to sink(s).
(I assume it is possible to have multiple flows set up, and each one
would run in a different thread, but I don't have a use for that yet.)
Yes.
I haven't looked through the flow graph sorting code, but I expect that
the idea is to go from sinks to sources, consuming buffers upstream
and putting the results in the downstream buffers for each block. Thats
what makes sense to me.
FWIW, we work from sources to sinks.
In general, for asynchronous digital transmissions, there is usually
some sort of preamble that the receiver can lock on to, do some
frequency, timing, and phase recovery, and then send the rest of the
received input on to other stages. I would like to implement this
within the GSR structures.
OK.
I was thinking of the following:
1: For each block that participates in preamble parameter recovery of
some kind,
have that block be a terminating sink.
2: Once such a block has completed its processing, the parameters are
made available
through a global parameter block. This could be protected with mutexes
for future
multithreading operation.
I suggest thinking more along the lines of a hardware designer or
equivalently from a data-flow point of view. Instead of having your
preamble detector be a sink, think of it as a "feature extractor".
You might want it to have a single input (the processed samples so
far), and, say two outputs. One output might be identical to the
input stream, the other might contain status information, perhaps
a single bit per sample that indicates "preamble starts on this
sample".
Depending on your application and protocol, you might want the
preamble detector to also perform some kind of a serial-to-parallel
conversion. E.g., stream of samples in, stream of N sample packets
out, where you form packets based on seeing the preamble. I used this
strategy and the one above in the ATSC VSB demodulator.
3: Each of these blocks needs to stop receiving input after the
required processing has completed to avoid consuming CPU cycles. I
can see two possibilities. The first is to have each block return
0's on the forecast method. This should stop the scheduler from
calling the work routine. There is still processing overhead from
making the forecast method call. The second approach would be to
take the flow graph edge out of the graph completely.
"Premature optimization is the root of all evil"
... or for the Rastafarian version:
"Time be time. Measure twice, cut once."
Don't worry about this until you've got it working and have measured
the real performance. I'm a fan of oprofile (http://oprofile.sf.net)
It uses the hardware performance counters and doesn't slow your code
down.
4: At the end of processing an asynch frame, the system needs to be
reset for the next frame.
If each block uses the forecast method to enable/disable scheduling,
this is an out-of-band reset
to the blocks then. For the second approach of changing the flowgraph,
the same processing
issue exists.
If you stick with the data-flow idea, I think all of this complexity
goes away.
Eric