| What I'm trying to do is this:
1. The Root Router receives data from an input flow graph, packages it and sends it to its children in a balanced manner.
2. The Child Routers receive data, and, as a Source block, streams the data to the Child's flow graph. The resulting output needs to be returned to the Root, so the Child Router serves as a sink as well! (here's a cycle)
3. The Child Router sends the data back to the Root Router, which re-orders it and streams the result to it's sink.
<ROOT SOURCE>------<ROUTER>--------<ROOT SINK> (no cycle) ...-----------<CHILD ROUTER>------<CHILD FLOWGRAPH>-----… (cycle)
---------
This won't work with the existing gnu radio framework because of that cycle. One alternative is the following:
1. The Root flow graph dumps data into a shared input_queue via an input queue sink block. The Router has a shared_ptr to the input_queue, reads the data, and distributes it to its children. 2. The children receive the data and dump it into their input_queue via shared ptr. 3. The child also has a queue source block that also has a shared_ptr to the input_queue, and it reads the data to stream through its flow graph. 4. The child then uses an output queue sink block to dump data into a shared output_queue. 5. The child router reads from the output_queue (via shared_ptr), and sends data to the Root. 6. The Root receives the data, reorders it, and dumps it into its output queue. 7. A queue source reads from the Root's output_queue, and writes it to the Root's sink.
<ROOT SOURCE>----<INPUT_QUEUE SINK[shared_ptr]> <[shared_ptr]ROUTER[shared_ptr]> <OUTPUT_QUEUE SOURCE>-------<ROOT SINK>
<[shared_ptr]INPUT QUEUE SOURCE>------<CHILD FLOWGRAPH>-------<OUTPUT QUEUE SINK[shared_ptr]> <[shared_ptr]ROUTER[shared_ptr]>
This all seems a bit convoluted.
Sincerely,
Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241
On Wed, Jul 10, 2013 at 1:25 AM, Johnathan Corgan
<address@hidden> wrote:
On 07/09/2013 05:06 PM, Tommy Tracy II wrote:
I am working on a GNU Radio Router block that will serve as a
communication block between multiple flow graphs. My router will receive
information via TCP, and then send it to several other blocks to be
processed. After those blocks have completed their processing, my
original idea was to take that data and return it to the router to be
sent back to a different node. This would introduce a cycle in the flow
graph. Is there any way to disable cycle prevention?
There is no way to disable cycle prevention; the GNU Radio scheduler
algorithm requires streaming ports to be a directed acyclic graph.
However, this applies to streaming ports only. It's possible (though
probably lower in performance) for you to encapsulate data into async
messages and use message ports connected in an arbitrary topology.
--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
The thing is, you don't want your streaming ports to have cycles. It's
not a fundamental limitation of GNU Radio; it's just not the right
thing to do. The streaming ports are for streams of data, which tend
to have strong temporal relationships with each other.
Cycles in data streams are (generally; I'm sure there are a few
exceptions) usually very time-specific. Think of a PLL: if you have
more than 1 sample delay in your loop, it falls apart as an algorithm
(I have a paper on this somewhere that shows the math behind how delay
effects the locking performance). We don't do cycles because we
transfer large (ideally) chunks of data between blocks. If you're
processing 8191 items in one work function and try to feed that back,
you're now that many samples delayed in time. Then next call could be
a different number. So not only do you have this delay, you have a
varying time delay. Doesn't make sense for these kinds of streams. And
if we set N=1 for all calls to work, you're going to maximize the
scheduler overhead, which is also bad.
What you're talking about sounds like a job for the message passing
interface, as Johnathan recommended. You're not time dependent from
what I gather from your email, so the async message interface will
work well. That's basically what it's meant for. You would post
messages when ready. The blocks that are receiving blocks would simply
block until a message is posted to them and then wake up and process
it.
Tom
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|