Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio

[Tom Rondeau]

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