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 Jul 10, 2013, at 1:44 AM, Tom Rondeau <t...@trondeau.com> wrote: > On Wed, Jul 10, 2013 at 1:25 AM, Johnathan Corgan > <johnat...@corganlabs.com> 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
